IRIS Development Option 6.2

home *** CD-ROM | disk | FTP | other *** search

/ IRIS Development Option 6.2 / IRIS_Development_Option_6.2_814-0478-001.iso / dist / WorkShop.idb / usr / relnotes / WorkShop / ch5.z.z / ch5.z / ch5

Wrap

Text File | 1996-03-14 | 118KB | 2,839 lines

- 1 - 5. _K_n_o_w_n__P_r_o_b_l_e_m_s__a_n_d__W_o_r_k_a_r_o_u_n_d_s 5.1 _W_o_r_k_S_h_o_p__D_e_b_u_g_g_e_r +o The ability to unwind the call stack using the Call Stack View does not work reliably. Stack traces will be incomplete when stopped in a signal handler of a 4.X binary running on a 5.X or a 6.X system. Returning from the signal handler using "step into", "step over" and "return" will not work correctly. Similarly, registering a signal through sigaction call with the SA_SIGINFO flag set may cause incorrect stack traces when stopped in the signal handler. (Incident #215151) Workaround: There is no good workaround for this problem. +o On 5.X, 6.0, and 6.1 systems the debugger has trouble detecting mismatches between an executable and core file (the problem is resolved on 6.2 systems). If this problem occurs, you are likely to receive an incorrect stack trace without any warning that the core file may not be based on the given executable. (Incident #186347) +o The views that do expression evaluation, Expression View, the Evaluate Expression dialog box, Structure Browser, Variable Browser, Array Visualizer, and the Debugger command line cannot yet evaluate: - long double (C/C++) and unsigned variants - real * 16 (Fortran) and unsigned variants - complex *32 (Fortran) and unsigned variants Evaluation of these types is not available at this time. (Incident #206313) +o Making an interactive function call when the target process is sleeping in a system call will cause the target to fault. (Incident #223601) +o WorkShop does not accommodate text editors other than Source View very well. Workaround: Set the _e_d_i_t_o_r_C_o_m_m_a_n_d resource in the _a_p_p-_d_e_f_a_u_l_t_s file to your desired editor. For example, set _e_d_i_t_o_r_C_o_m_m_a_n_d to _w_s_h -_c _v_i +%_d to run _v_i in a _w_s_h window. You also need to set *_u_s_e_T_o_o_l_T_a_l_k to _F_a_l_s_e. - 2 - +o The request to kill a process which has spawned child processes (through _f_o_r_k(), _s_p_r_o_c(), or _s_p_r_o_c_s_p()), followed by exiting _c_v_d, may not properly terminate the descendant processes. The descendant processes may continue to run after _c_v_d has exited. (Incident #206273) Workaround: Kill all of the process group members with the Multiprocess View as opposed to using the Main View. If any of the descendant processes were created through a _f_o_r_k(), you will have had to direct the Multiprocess View to attach to _f_o_r_k()ed process (see ``Config: Preferences'' in the Multiprocess View). +o The Multiprocess View is known to occasionally not display all process group members which _c_v_d is attached to. One condition where this problem occurs is when the list of processes shown by the Multiprocess View is frequently changing in a short span of time (for example, processes are _f_o_r_k()ed which _e_x_e_c() and exit shortly after they start). (Incident #244782) Workaround: Use of Stop in the Multiprocess View will cause _c_v_d to stop all process group members and the display should change to correctly list all processes. +o When _c_v_d is brought up on one member of a running shared process group (see _s_p_r_o_c(2)), _c_v_d does not identify and attach to all of the other processes which are members of the shared process group. If you start up the Multiprocess View you will only see the process you started _c_v_d on. The correct behavior from the Multiprocess View would be to display all members of the shared process group. (Incident #179940) Workaround: Use ``Process: Add'' in the Multiprocess View to manually add each member of the shared process group to the _c_v_d process group display by Multiprocess View. +o Attempts to add a process which has been removed from Multiprocess View may fail or lead to an abort of the Multiprocess View. (Incident #168934) +o Disassembly View sometimes has problems when two or more DSOs have overlapping text. In such cases, Disassembly View displays only one of the DSOs from the set whose text overlaps. This can happen to users who are building their own DSOs. Unfortunately _c_v_d does not warn the user when this type of conflict occurs. (Incident #204024) - 3 - +o On attempting to locate the DSOs used by an executable, _c_v_d uses the shell environment in which _c_v_d was started, as opposed to the shell environment within the Execution View. This means that the value of environment variables like LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYY____PPPPAAAATTTTHHHH which are used by _c_v_d may not match the values in the shell where the executable will be run. When _c_v_d is using the wrong values for environment variables like LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYY____PPPPAAAATTTTHHHH, it may have trouble finding all of the appropriate DSO symbol tables. When _c_v_d has trouble finding DSOs used by an executable it will display the Library Search Path dialog to call attention to the DSOs which could not be found. (Incidents #224125, #236651) Workaround: Use ``Admin: Library Search Path ...'' to examine and set environment variables like LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYY____PPPPAAAATTTTHHHH which control the identification of DSOs. +o Watchpoints in _c_v_d may be defined with an address and size or an expression. If you attempt to watch an expression which resides on the stack (for example, a local variable) _c_v_d will not allow definition of the trap. _c_v_d will only watch expressions whose location is within a mapping other than the stack. (Incident #197233) Workaround: If you want to watch an expression which resides on the stack, use the expression evaluator to find the address of the expression and create the watchpoint using the address. Once the expression is deallocated, the watchpoint should be removed to avoid any confusion when the stack address is reused for some other purpose later on in the execution. +o Process group watchpoints involving expressions are not supported well. If you create a watchpoint with a command like ppppggggrrrrpppp wwwwaaaattttcccchhhh <<<<eeeexxxxpppprrrreeeessssssssiiiioooonnnn>>>>, the expression is only evaluated once on one of the process group members. The evaluation is used to determine the address and size of the watchpoint, and address and size is used to create a watchpoint on each process group member. This will only work correctly if the address and size of the expression is the same for each process group member. There is no workaround known for this problem. (Incident #143367) +o The Trap Manager fails to properly define watchpoints on 64-bit addresses. The address typed in the ``Trap:'' field is corrupted and either a watchpoint is - 4 - created on the wrong address or an invalid address error is reported (_W_a_t_c_h_p_o_i_n_t _a_d_d_r_e_s_s _r_a_n_g_e _i_n_c_l_u_d_e_s _a_n _i_n_v_a_l_i_d _v_i_r_t_u_a_l _a_d_d_r_e_s_s.). (Incident #235635) Workaround: The command line interface panel in the _c_v_d Main View can be used in place of the Trap Manager to enter the watchpoint command. +o _c_v_d does not have support for weak symbols (see Appendix A of the _C _L_a_n_g_u_a_g_e _R_e_f_e_r_e_n_c_e _M_a_n_u_a_l). _c_v_d will not recognize the weak symbol name. For example, _c_v_d will not accept a request to trap on entry to dlopen. (Incident #181409) Workaround: Use the "strong" symbol name in place of the weak one. Many weak symbols defined in libc have corresponding "strong" symbol names which are the weak name with a ``_'' prepended onto the front. For example, the "strong" symbol name for dlopen is _dlopen. +o A write watchpoint may fail to fire when the write occurs within a syscall. For example, a write watchpoint on one word within a buffer written by read may fail to fire. Workaround: Define the watchpoint to cover the entire data structure as opposed to a subset of the structure. For example, define the watchpoint over the entire buffer being handed to read as opposed to a single word. +o An attempt to step into the first call to an external function will behave like a step over. The first call to an external function invokes rld to resolve the function address. When this occurs the request to step into the call will look like a step over to the user. (Incident #147302) Workaround: Either set the environment variable _L_D__B_I_N_D__N_O_W to 1 in the Execution View prior to running the program (see _r_l_d(1)) or use function entry breakpoints. +o Traps placed within a parallel Fortran DO loop, created with the C$DOACROSS compiler directive, fail to work correctly. Although the traps appear to be placed correctly on 6.0 systems, the process will not stop on the traps. On 5.3 systems the traps cannot be placed within the loop at all. (Incident #20818) - 5 - Workaround: On a 6.0 system _d_b_x can be used successfully to place traps within the loop. +o The Fortran intrinsics _c_h_a_r, _z_e_x_t, _s_e_c_o_n_d_s, _m_a_l_l_o_c, and _e_p are not supported. (Incident #206293) +o The debugger does not understand external or intrinsic statements in the Fortran program. If the program has a function by the same name as an intrinsic function, evaluating an expression involving that function will always cause the program function to be called. +o Some of the intrinsics (_s_q_r_t, _e_x_p, _l_o_g, _l_o_g_1_0, _s_i_n, _c_o_s, _t_a_n, _a_s_i_n, _a_c_o_s, _a_t_a_n, _s_i_n_h, _c_o_s_h, _t_a_n_h) do not give the correct results when the debugged executable is linked with _l_i_b_m._s_o. This is because of entry points with similar names in _l_i_b_m._s_o. Workaround: Use a specific intrinsic name. For example, _s_i_n(_r_1) where _r_1 is real will produce incorrect results. On the otherhand, _d_s_i_n(_d_f_l_o_a_t(_r_1)) will give correct results, with the results being a _r_e_a_l *_8 quantity. +o Stopping in the entry prologue of a function (before the first user statement) in a Fortran program and evaluating an expression that involves an adjustable array or displaying an adjustable array in the Array Visualizer will not work correctly. (Incident #206264) Workaround: Step to the first user statement and evaluate the expression. +o When stopped in a Fortran function/subprogram that has alternate entry points, the debugger will not list all the arguments of the subprogram and their values correctly. (Incident #164327) +o For global lookups, _c_v_d acts as though all DSOs are built ----BBBB ssssyyyymmmmbbbboooolllliiiicccc. If a process is stopped within a DSO and the user asks _c_v_d to lookup a global variable or function, _c_v_d will always look within the DSO before it considers the main program or any other DSO. In effect, _c_v_d is acting as if each DSO has been built with ----BBBB ssssyyyymmmmbbbboooolllliiiicccc. (Incidents #173343) +o Interactive calls to inline member functions of C++ classes is not supported. +o There is no support for C++ overloaded operators in the expression evaluator. (Incident #203968) - 6 - +o The debugger does not have full support for C++ templates. However, the user can stop in template code and print the ``this'' pointer. (Incidents #140313, #140316, #222352) +o The display format for describing an array pointer types is incorrect. For example, an array of double(*)[2] is expressed as double[]*. +o Elements of Fortran arrays with more than 6 dimensions (or 5 dimensions, if the element type is character string) cannot be referenced. +o C++ objects containing virtual base classes do not display correctly in the expression evaluator. (Incident #190170) +o _c_v_p_c_s can stack trace through assembler alternate entry functions only when they are at the same address as the main entry point. Assembler functions with arbitrary alternate entry points will produce incorrect stack trace. +o When the Trap Manager is invoked, traps are automatically loaded from the ._c_v_T_r_a_p_M_g_r file if one exists. However, these traps are reloaded if the Trap Manager is closed and restarted. (Incident #79217) Workaround: The Trap Manager should either be left running or the default traps should be stored in a different file and reloaded manually when desired. +o In general, when a write watchpoint fires, the write is simulated by the debugger to show the new value before any trap conditional is evaluated. The four exceptions for this case are the SC, SCD, SDL, and SDR instructions. (Incident #250036) +o A kernel bug prevents watchpoints from firing reliably for members of share process groups (such as Power Fortran or Power C programs). Watchpoints work reliably for non-shared text and data segments in each individual process. +o If you stop a process through job control, the debugger may not display an accurate status of the process, and process control requests do not take effect until the process is resumed through job control. A process is stopped through job control with <Ctrl-Z> from the shell or when it receives one of the signals: SIGSTOP, SIGTSTP, SIGTTIN, and SIGTTOU. A process is resumed - 7 - through job control with _f_g and _b_g from the shell or when it receives the signal SIGCONT. If a running process is stopped through job control, the debugger continues to show that the process is running. When attaching to a process stopped through job control, the debugger shows that the process is stopped. (Incident #167693) +o For instrumented executables (used for performance analysis), stack frame unwinding may be incomplete when stopped in a signal handler; the unwinding may stop prematurely after the ``_sigtramp'' frame. (Incident #71307) Workaround: A full stack trace may be maintained by returning past the ``_sigtramp'' frame. +o The demo program _j_e_l_l_o cannot be built as described in the tutorial without the library /_u_s_r/_l_i_b/_l_i_b_g_l._s_o. Workaround: This library should be installed when IRIX is installed (eoe1.sw.gfx_lib subsystem). +o Processes that use the blocking capabilities as provided by _b_l_o_c_k_p_r_o_c(2) may not terminate as expected upon completion of a debug session. Such processes are left in a blocked state with a SIGKILL pending. Workaround: These processes can be terminated with _k_i_l_l(1). +o The modification of an inactive trap will cause the trap to become active. You will have to toggle the active button next to the trap description in order to deactivate the trap. (Incident #190278) +o There is a case where the path remapping component of WorkShop will find the wrong file. When _c_v_d is stopped and started multiple times, and ``Admin:Exit'' was used to exit _c_v_d, the path remapping component will retain entries in its Substitution Set from each debugging session (see ``Admin:Project:Remap Paths...''). The path remapping component of _c_v_d is implemented as a separate process and the ``.'' entry in the Substitution Set refers to the directory in which the process was started, typically the directory were the first _c_v_d was started. Workaround: Use ``Admin:Project:Exit'' in place of ``Admin:Exit''. This will force the path remapping process to terminate on each exit of _c_v_d. - 8 - +o By default the debugger will not attach to a _f_o_r_k()ed process unless the fork occurs during an interactive function call. If you have used the Multiprocess View preferences dialog to prevent a forked child from being resumed, and you make an interactive function call will leads to a call on fork, the child process will be left stopped on exit from fork. You must now use the Multiprocess View to resume the child process. (Incident #190308) +o _c_v_d may fail to recognize that a DSO source file is newer than the DSO. Although such a source file may be the wrong version for the code which is executing, _c_v_d will not issue a warning. The source of the problem is that _c_v_d is always comparing time of last modification for the source file against the executable when it should be comparing against the DSO. (Incident #181297) +o Fortran COMMON block members that are at an offset greater than 8 Megabytes from the start of the common block will not be evaluated correctly in an expression. +o When using the Switch Process dialog to attach to an existing process, don't attach to one of the CaseVision or WorkShop processes (e.g. _c_v_p_a_t_h_R_e_m_a_p, _c_v_m_a_i_n) or the environment may hang. Should this happen, kill the _c_v_m_a_i_n process and start over. +o Occasionally, _c_v_m_a_i_n will dump core at startup if you have an executable with a mismatched core file and your NetLS license is within 90 days of expiring. If this happens, restart _c_v_d. +o The request to print the content of a very large data structure (such as an array) from within the main window's command line interface panel may lead to an abort of _c_v_d. (Incident #227980) Workaround: The Array Browser may be used to display very large arrays. +o The main window's command line interface panel will only display the first 100 elements of an array. There is no way to change this behavior. (Incident #250028) Workaround: The best way to examine an array is the Array Browser. +o With an executable built with the DCC compiler, attempts at retrieving symbolic information about - 9 - _o_s_t_r_e_a_m may lead to an abort of _c_v_p_c_s. Entering the command wwwwhhhhaaaattttiiiissss oooossssttttrrrreeeeaaaammmm in _c_v_d will lead to such an abort. (Incident #239838) +o The _c_v_p_c_s component of _c_v_d is known to abort on very large COFF format executables. (Incident #244495) +o The command line interface panel in the _c_v_d Main View may fail to evaluate expressions when the process is stopped and the language of the current context is Assembler. (Incident #246294) Workaround: The Expression View can be used in place of the command line interface panel. +o After a process has stopped, an expression value may become invalid due to evaluation of another expression or use of debugger commands which can lead to modification of expression values. An example would be the value of a variable displayed in Expression View which is not recalculated after the variable is updated with the _a_s_s_i_g_n command in the command line interface panel. (Incident #247050) Workaround: Force the value of the expression to be recalculated by retyping the expression. +o The Array Visualizer will no longer implicitly use _t_h_i_s on a C++ program. When attempting to display the member of a class you will have to explicitly include _t_h_i_s-> along with the name of the member. (Incident #248882) +o Use of the division, and modulus operators in the ``Indexing Expression:'' field of the Array Visualizer may not work correctly on 64-bit executables. (Incident #249262) +o On startup _c_v_d connects to an underlying process control server. Due to a change in WorkShop 2.4, when _c_v_d is using a version of the communication protocol which is incompatible with the version used by the server it can no longer recognize the condition and report the incompatible version numbers. As in previous versions of WorkShop, _c_v_d will exit, but it will no longer report the mismatch of communication protocol versions. (Incident #233399) +o _c_v_d may not list all the member functions of a class correctly when the class and its member functions are built into a separate DSO. (Incident #249733) - 10 - +o If the application uses the isolate process (or CPU pinning) feature of IRIX, the thread pinned to a specific CPU cannot be debugged. The isolate process feature is accessed by a call to _s_y_s_m_p(_M_P__I_S_O_L_A_T_E). (Incident #216158) Workaround: Disable calls to _s_y_s_m_p(_M_P__I_S_O_L_A_T_E) to enable debugging. +o Occasionally, path remapping will cease to function properly: new entries in the list will not take immediate effect, yet if you exit and restart _c_v_d, they will apply. (Incident #247133) Workaround: Exit _c_v_d and kkkkiiiillllllllaaaallllllll ttttttttsssseeeessssssssiiiioooonnnn. +o _c_v_d cannot evaluate expressions involving local classes (classes that are defined inside of a function). (Incident #212268) +o The Query menu within _c_v_d will fail to operate correctly if _c_v_d was attached to a running process (ccccvvvvdddd ----ppppiiiidddd ............) or if _c_v_s_t_a_t_i_c is started by hand (``Admin: Launch Tool -> Static Analyzer''). (Incident #238595) +o A trap at the closing brace of a C/C++ function may not be defined properly. This is known to occur when the last statement of the function is a return statement. When this problem occurs the trap is defined on a source line following the closing brace, typically the opening brace of the next function. Workaround: Place the trap on the source line containing the return statement as opposed to the line containing the closing brace. (Incident #277136) +o _c_v_d may close file descriptors it should leave open in the _r_u_n command. All file descriptors at 3 and above are closed by _c_v_d. (Incident #277295) +o The Structure Browser is known to abort when asked to display more than 100 elements of a linked list. (Incident #278140) +o The _c_v_p_c_s component of _c_v_d is known to occasionally abort on erroneous expression evaluation requests from the one-time expression evaluation component of _c_v_d. (Incident #282160) +o Evaluation of a C++ expression which contains a variable whose name is the same as that of a structure - 11 - may lead to an erroneous error. (Incident #286949) 5.1.1 _D_e_b_u_g_g_i_n_g__6_4_-_b_i_t__a_n_d__N_3_2__C_+_+__p_r_o_g_r_a_m_s This section discusses problems that are unique to debugging 64-bit and N32 C++ programs. (The problems discussed in the previous section may also apply to 64-bit and N32 C++ debugging.) The first two problems on the following list are limitations of this release of the debugger; they will be fixed in a future release. The remaining problems will be fixed by a future release of the C++ compiler. +o Interactive function calls to member functions cannot be performed through objects of the class using the -> or . access operators. Workaround: Perform the interactive function call using the class-qualified name. In such a call, the _t_h_i_s parameter must be passed explicitly. ccccllllaaaassssssss nnnnooooddddeeee {{{{ nnnnooooddddeeee ****____rrrriiiigggghhhhtttt;;;; nnnnooooddddeeee ****____lllleeeefffftttt;;;; ppppuuuubbbblllliiiicccc:::: nnnnooooddddeeee(((())));;;; nnnnooooddddeeee**** rrrriiiigggghhhhtttt(((())));;;; nnnnooooddddeeee**** lllleeeefffftttt(((())));;;; }}}};;;; nnnnooooddddeeee ****nnnn;;;; In this example, the member functions cannot be called as _n->_r_i_g_h_t() or _n->_l_e_f_t(). Instead, they must be called as _n_o_d_e::_r_i_g_h_t(_n) or _n_o_d_e::_l_e_f_t(_n). +o The _t_h_i_s parameter is not explicitly dereferenced in member functions. Workaround: Access members of the _t_h_i_s parameter in a member function by using the _t_h_i_s-> accessor. +o There is no debugging output for anonymous unions declared in a block. (Incident 236926) +o Static data members cannot be accessed using the -> or . access operators. (Incident 237006) Workaround: Access static data members using the class-qualified name. +o Static member functions cannot be accessed using the -> or . access operators, or by using the class-qualified - 12 - name. (Incident 237029) Workaround: Access static member functions using only the name of the member function; do not use the class- qualified name. +o Nested C++ classes appear as global classes. (Incident 242800) +o The tag for nested C++ structures is incorrect. Instead of the correct tag name, the C++ mangled name is used. (Incident 244522) +o The type is incorrect for point-to-member variables. Instead of having the correct pointer-to-member type, these variables have the type of the member to which they're pointing. (Incident 249844) +o The definition of a template class instantiation does not include the member functions. (Incident 249849) Workaround: A member function definition for a template class instantiation may be printed out using the class-qualified name, prefixed by the template argument list. For example, consider the following code segment: tttteeeemmmmppppllllaaaatttteeee<<<<ccccllllaaaassssssss TTTT>>>> ccccllllaaaassssssss vvvveeeeccccttttoooorrrr {{{{ TTTT**** vvvv;;;; iiiinnnntttt sssszzzz;;;; ppppuuuubbbblllliiiicccc:::: vvvveeeeccccttttoooorrrr((((iiiinnnntttt))));;;; TTTT&&&& ooooppppeeeerrrraaaattttoooorrrr[[[[]]]]((((iiiinnnntttt))));;;; }}}};;;; vvvveeeeccccttttoooorrrr<<<<iiiinnnntttt>>>> vvvv1111((((22220000))));;;; In this example, the global names of the member functions are <_i_n_t>_v_e_c_t_o_r::_v_e_c_t_o_r and <_i_n_t>_v_e_c_t_o_r::_o_p_e_r_a_t_o_r[]. 5.1.2 _D_e_b_u_g_g_i_n_g__P_r_o_g_r_a_m__G_r_o_u_p_s__I_n_c_l_u_d_i_n_g__a__S_e_t_-_u_i_d__P_r_o_g_r_a_m Because of standard IRIX security policies, the debugger can not debug a program running as another user (unless you are logged in as _r_o_o_t). This restriction applies even to system programs which are set-UID, and even when all you want to do with the set-UID program is debug something that it in turn runs. It is common to use the system-provided set-UID program _x_w_s_h (or _w_i_n_t_e_r_m, which in turn runs _x_w_s_h) in this way. There are two basic ways to deal with this problem. You can become _r_o_o_t before starting your debugging session, which - 13 - grants you all necessary access rights (but may be infeasible for your application or situation). Or, you can arrange to use a non-set-UID copy of the intermediary program, for example with _c_h_m_o_d, or by making a copy of the program with _c_p. There is also a bug in the IRIX 6.0 version of _x_w_s_h which makes it unreliable if run non-set-UID. You may be able to use _x_t_e_r_m instead of _x_w_s_h for these applications, for example by using _w_i_n_t_e_r_m and setting the environment variable WWWWIIIINNNNTTTTEEEERRRRMMMM to xxxxtttteeeerrrrmmmm before starting your debugging session (and providing a non-set-UID copy of _x_t_e_r_m). If your application depends on features of _x_w_s_h, can not use _x_t_e_r_m instead, and can not be run as _r_o_o_t, then this procedure will generally ensure that you can debug as non- root: +o Make a non-set-uid copy of _x_w_s_h (ccccpppp ////uuuussssrrrr////ssssbbbbiiiinnnn////xxxxwwwwsssshhhh ....). +o Start several _x_w_s_h or _x_t_e_r_m windows, as the user who will be doing the debugging. Exit them all. It is important that they all be started together, all be running at once, and then be exited immediately before the debugging session begins. +o Debug your application. +o Set one or more breakpoints by function name ("stop in main"), in the syscall panel, or with the ``Traps: Stop at Function Entry'' menu - not by clicking in the glyph bar of the main window. (Traps set on a particular source line, as by clicking, are not copied from one program to the next.) +o Bring up the MPView, from the Admin menu. +o Be sure all the "copy traps...." boxes are checked in its configuration dialog. +o Run your application, using MPView's ``Continue'' button as necessary and watching MPView for the appearance of your subprocess. Double-click it to launch a debugger on it. - 14 - 5.2 _W_o_r_k_S_h_o_p__F_i_x_+_C_o_n_t_i_n_u_e 5.2.1 _L_i_m_i_t_a_t_i_o_n_s__o_f__F_i_x_+_C_o_n_t_i_n_u_e +o You cannot add or delete global variables or functions. +o You are restricted to editing the bodies of existing non-inline functions. If you attempt to edit an inline function, no warnings are emitted, but the results are unpredictable. Incident 240481 +o You cannot modify a function while the program is sleeping in a system call, or is stopped on entry to a system call. The debugger will detect this condition and prevent you from loading the modified function until you return from the system call. You can set a trap on exit from the system call using the System Call panel of cvd and continue the program in order to get to a point where function loading is allowed. Incident 244664 +o The Multiprocess View capability of the debugger does not interact well with the Fix and Continue feature. sproc'ed and forked processes inherit the new redefinition of the function. However, when starting a debugger session on the new process, the debugger is not aware that the process contains function redefinitions. This means that there is no way to deactivate the new definition in the new process after a sproc() or a fork(). If the new function definition is not desired in the new process, it is necessary to stop the process on entry to fork() or sproc(), deactivate the modified function and activate it again on exit from fork() or sproc(). +o Performance Analysis and Fix and Continue are mutually exclusive operations. You should not run a performance experiment after you have modified a function. In most cases, the debugger will detect attempts to mix Performance Analysis and Fix and Continue operations, and prevent them. Incident 245326 +o The Fix and Continue feature is not supported for code compiled with the Delta/C++ (DCC) compiler. The current - 15 - implementation does not detect this problem. +o Fix and Continue can only be used on ELF executables compiled in shared mode. Fix and Continue is implemented by using the dynamic loader, which is not available in COFF or non-shared ELF executables. Incident 243574 +o Fix and Continue is only supported on Irix 5.3. In particular, Fix and Continue is not supported on Irix 5.2 and Irix 6.x. 5.2.2 _K_n_o_w_n__P_r_o_b_l_e_m_s__w_i_t_h__F_i_x__a_n_d__C_o_n_t_i_n_u_e +o The Disassembly View has not been updated to work with the Fix and Continue feature. As a result, you will notice the following behavior when viewing a modified function in Disassembly View: +o The filename displayed is incorrect, and reflects the name of the temporary file used by the Fix and Continue mechanism. +o The assembly instructions are not interleaved with the source code. +o The line numbers shown in Disassembly View do not reflect the line numbers used in the rest of the debugger (i.e., instead of "7.3", the Disassembly View will say line "9"). Incident 243635 +o The initialization value of local statics in C may not be modified. If you make such a change, it will silently be ignored. Since you are permitted to add new local statics, you can accomplish a change of the initialization value using the following workaround: - 16 - /* Original function */ void f() { static int i = 0; /* oops. This should be -1 */ } /* New function */ void f() { static int i = 0; /* oops. This should be -1 */ static int first_time = 1; if (first_time) { i = -1; first_time = 0; } } Incident 246306 +o In C it is legal to call a function without declaring it, and later declare the function to be static. For example: main(){ f(); return 0; } static int f(){ } Since the Fix and Continue feature will only compile "main", and since there is no declaration for "f", the compiler will assume that "f" is an external function, and there will subsequently by a "Load Error" in the Interpreter Message window since the runtime loader will be unable to find an external definition for "f". The workaround is to make sure the compiler knows that "f" is static when you use modify "main" during a Fix and Continue operation: main(){ static int f(); f(); return 0; } Incident 246317 +o When executing an older version of a function, you will see the most recent source in the source window. Consequently the line numbers, PC highlight, and breakpoints displayed may be on the wrong lines. - 17 - +o If you open a source file using "Source:Open...", the source file is opened in "Editable" mode by default. This prevents Fix and Continue operations on the file, and you will see the "Fix+Continue" button grayed out. If you wish to use Fix and Continue on this file, use the "Source:Make Read Only" menu option. If you use "Source:Open..." to open a source file in which you have previously modified functions, the modified functions will not be highlighted while the source file is editable. If you save a file in which some changes were made using Fix and Continue, and some changes were made using "Source:Open...", confusion may occur. You can workaround this by using "Source:Make Editable" followed by "Source:Make Read Only". Another workaround is to switch to some other file and then switch back to the current file. Switching back can be accomplished by making the process stop in the file or by using "Source:Open..." followed by "Source:Make Read Only". Incidents 243627, 243629, 248842 +o If you are stopped in a program, and you modify a function which is not the one you are stopped in, after the "Parse And Load" completes your source is repositioned at the line on which you are stopped, rather than at the function you just modified. Incident 246739 +o When a "Parse and Load" is performed, a compiler is invoked to compile the modified function. Before performing the compile, the compilation process will do a "cd" so that the compilation takes place in the same directory as the original file was compiled in. This "cd" operation does not currently take path remapping into account, so you will have problems when you attempt to use "Fix and Continue" on an executable which was built on a different machine. The workaround is to make sure that you use "Fix and Continue" on an executable in the same environment as the one it was built in. Another alternative is to adjust the command line options on the compile command (using the Build Environment window) so that they will work in the debugging environment. Incident 246189 +o The Fix and Continue mechanism does not currently check to make sure that a file has not been modified after it - 18 - was last compiled. If you modify a function using Fix and Continue, save the source back to its original file, and forget to rebuild your application after exiting the debugger, you will see unpredictable result if you re-enter the debugger and attempt to use Fix and Continue. For example, the debugger may think that function "f" is on lines 15 to 20, whereas your previous changes may have repositioned the function on lines 17 to 22. When you select "Fix+Continue:Edit" if you notice that the edit region does not cover the entire body of the function, you should exit the debugger and rebuild your application. Incident 245098 +o If your original build compiled multiple files with a single command line, this same command line will be run when using Fix and Continue to modify a function in any of those files, causing unnecessary recompilations of the other files, and possibly erroneous results. For best results, compile files one at a time using the -c option of the compiler. If this is not possible, use the Build Environment view to modify the command line and remove all file names from it (Fix and Continue will add in the file actually being compiled automatically). +o When you use the "Fix and Continue->Edit" menu item, the region you are allowed to edit begins with the line containing the first "{" of your function. This line would include the line containing the function and parameter declaration, for the coding style shown below: void f(int y){ /* .... */ } In such cases, you should make sure you do not change the function name and parameter profile. The implementation does not currently check that you do not make such changes, but you may receive a message like this: No reply from PCS; unknown error while loading dso for the modified function Incident 245299 +o If a "stop exit" trap is placed in a function, and Fix and Continue is used on the function after hitting the - 19 - exit trap, then if execution can continue in the new function, the PC is moved back to the beginning of the line (it is in the epilogue, at the "jr ra" instruction). This means the epilogue is re-executed. This could cause problems if the stack pointer has already been decremented, because now it will get decremented twice. Your program may occasionally work if the stack decrement happens to be after the "jr ra" instruction. The implementation currently does not always detect this condition. The workaround is to reposition the PC at the "jr ra" using PC->JumpTo after your F&C has completed. F&C and templates +o Using F&C on functions which use templates are not completely supported in this release. Typically, if the change involves instantiating new functions, then such a change is not supported in this release. If the process is stopped when this change is made, the F&C error message window will display the error message from rld under the PCS error messages. Otherwise, views would temporarily show that the change is ok, but when the process is run later , load error message will be reported and the change is switched back to edited state. The error message would be something like: : 26095:/tmp_mnt/hosts/xanadu/usr/people/pal/kim/mnm: rld: Fatal Error: unresolvable symbol in /var/tmp/cvintp26042/cvfn1.3.so: static_allocator__15vector__pt__2_i Incident 249309 5.3 _W_o_r_k_S_h_o_p__M_o_t_i_f__A_n_a_l_y_z_e_r +o The Motif Analyzer requires Irix 5.3 for correct operation. The instrumented libraries have been tested only with an Irix 5.3 environment. Using them with an older version of Irix may result in compatibility problems with other shared libraries. +o The Motif Analyzer may produce unexpected results when used with an application compiled on a pre-Irix 5.3 system using static libraries, and with non-Motif (e.g. Xaw) applications. In particular, the widget selection and widget tree functionality may not work. - 20 - +o The instrumented, debug Motif library shipped with the MegaDev.sw.motif subsystem and installed in /usr/lib/WorkShop/Motif contain the Irix 5.3 version of motif_eoe.sw.eoe up to and including patch 258. If you are debugging a Motif-related problem in your application and the problem is not reproducible using the instrumented Motif library in /usr/lib/WorkShop/Motif, it may be fixed with the patch 258 version of motif_eoe.sw.eoe. +o If you create traps in the Motif Analyzer window using the Breakpoints examiner, trap items will appear in the Trap Manager window of the WorkShop Debugger. These items will be labeled "MotifBreak." You should not attempt to modify or delete these traps using the Trap Manager. Instead, always use the Breakpoints examiner to modify or delete your Motif-related breakpoints. +o If you install the MegaDev.sw.motif subsystem and then reinstall the WorkShop.sw.cvd subsystem, the "Motif Analyzer" item will disappear from the Views menu in the WorkShop Debugger. Reinstalling the MegaDev.sw.motif subsystem will correct the problem. +o If you install the WorkShop.sw.cvd and MegaDev.sw.motif subsystems, and then remove only the MegaDev.sw.motif subsystem, the "Motif Analyzer" menu item will still exist in the Views menu in the WorkShop Debugger. Selecting this menu item, however, will result in an error dialog. Reinstalling the WorkShop.sw.cvd subsystem will remove the item from the Views menu. +o Occasionally, the Motif Analyzer display will remain inactive after switching between processes using WorkShop's "Switch Process" or "Switch Executable" menu items, or when rerunning the process after changing the command arguments. If this happens, close the Motif Analyzer window and use WorkShop's Views menu to bring it up again. +o If your application connects to a remote X display and you do not set LD_LIBRARY_PATH to include /usr/lib/WorkShop/Motif, any Editres-type operations (e.g. widget select and widget tree) will operate on the local display and not work correctly. Either run your program using the local X display or change LD_LIBRARY_PATH as advised. +o A small number of applications build their widget hierarchy in such a way that Editres widget selection operations cause them to exit with an X error. If your - 21 - application falls into this category, then using the Motif Analyzer widget select functionality will cause the same thing to happen. 5.4 _W_o_r_k_S_h_o_p__B_u_i_l_d__A_n_a_l_y_z_e_r If target or dependency names are specified using parentheses to denote files stored within an archive library, _c_v_b_u_i_l_d will use a single node to represent the archive library, rather than individual nodes for each file within it. 5.5 _W_o_r_k_S_h_o_p__S_t_a_t_i_c__A_n_a_l_y_z_e_r 5.5.1 _G_e_n_e_r_a_l__K_n_o_w_n__P_r_o_b_l_e_m_s +o The Directory Query "List Files" works only when the query target is a full path name of a directory. For example, it works on the target "/usr/include", but not on a target like "include". Workaround: Select the General Option "Full Pathnames". Then any directory names displayed will contain full paths, and so the "List Files" query will cork on them correctly. +o If you use _c_v_s_t_a_t_i_c to analyze a fileset and then change one or more of the header files included by the files in the fileset, rescanning the fileset will not detect the change. Rescanning only detects changes to source files listed in the fileset. Similarly, if you remove a source file from a fileset and rescan, the header files included by that file are not removed from the database. (Incident #179731) Workaround: If you have changed one or more files in a fileset (or included by files in a fileset), you can get a consistent database by selecting ``Force Scan'' from the Admin menu. +o Some printers may clip the output when printing a PostScript version of graph saved by _c_v_s_t_a_t_i_c. Workaround: None, except trying another printer, or re-laying out the graph by hand to avoid clipping. 5.5.2 _K_n_o_w_n__P_r_o_b_l_e_m_s__w_i_t_h__M_i_x_e_d__L_a_n_g_u_a_g_e_s - 22 - +o If you analyze a program that contains both Fortran and C routines, _c_v_s_t_a_t_i_c in scanner mode does not recognize that the C function ffffoooooooo____ and the Fortran function ffffoooooooo refer to the same routine. In parser mode, _c_v_s_t_a_t_i_c will identify the routines correctly, if it analyzes the C file containing ffffoooooooo____ before the Fortran file that calls ffffoooooooo. So, make sure that your C files appear earlier in the fileset than your Fortran files. - 23 - 5.5.3 _G_e_n_e_r_a_l__K_n_o_w_n__P_r_o_b_l_e_m_s__i_n__S_c_a_n_n_e_r__M_o_d_e +o In general, _c_v_s_t_a_t_i_c does not require code to be able to be compiled. _c_v_s_t_a_t_i_c should provide useful information even when code has syntax errors. However, there are several requirements that must be met for _c_v_s_t_a_t_i_c to work properly. In C and C++, _c_v_s_t_a_t_i_c relies on the existence of matching braces to determine the beginning and ending of blocks and bodies of functions. In Fortran, _c_v_s_t_a_t_i_c relies on the existence of matching end statements. Functions without closing braces, or end statements, or code with too many end statements or mismatched braces can cause unpredictable results. In C, it may be necessary to use _c_v_s_t_a_t_i_c's ----pppprrrreeeepppprrrroooocccceeeessssssss option with heavily _i_f_d_e_f'd code to achieve matched braces. If any of these limitations of scanner mode keeps _c_v_s_t_a_t_i_c from being useful, using parser mode may be the right solution. +o _c_v_s_t_a_t_i_c accepts regular expressions in nearly all fields. This can occasionally cause problems if you unintentionally use a pattern without realizing it is a regular expression. For example, specifying a filename of ffffoooooooo....cccc++++++++ usually fails, because ++++ is a special character in regular expressions. Workaround: Backslash all regular expression special characters when not used to specify a wildcard pattern. For example, the filename mentioned above would be entered as ffffoooooooo....cccc\\\\++++\\\\++++. +o The _c_v_s_t_a_t_i_c Variable query, ``Who Sets'' recognizes only variable assignments that use ``='' to assign directly to a variable. This query does not recognize or account for aggregate initialization statements in C or C++, references in C++, assignments made as a result of passing or operating on pointers in C, or data, equivalence, common, or assign statements in Fortran. Workaround. Use ``Who References'' to see all locations in which the variable is used and to visually inspect for assignments. +o By default, _c_v_s_t_a_t_i_c does not honor _i_f_d_e_f's in source code. Much of the time, this is desirable behavior. _c_v_s_t_a_t_i_c allows you to find _a_l_l references that satisfy a query. However, this may result in an incorrect or misleading function call tree. Heavily _i_f_d_e_f'd code may - 24 - also confuse _c_v_s_t_a_t_i_c, because (in C) _c_v_s_t_a_t_i_c relies on matching braces to detect the end of functions. Workaround: Use the ----pppprrrreeeepppprrrroooocccceeeessssssss flag when starting _c_v_s_t_a_t_i_c. This makes _c_v_s_t_a_t_i_c run much more slowly, but it honors most _i_f_d_e_fs. +o _c_v_s_t_a_t_i_c recognizes many common C, C++, and Fortran language patterns. However, all three languages allow programmers to write code that is not easily identified by patterns. Workaround: If you find that _c_v_s_t_a_t_i_c misses or misidentifies parts of a program, you can usually resort to string, regular expression, or symbol queries to find the information you are looking for. +o Files containing very long lines are not handled in scanner mode. If a file contains any line longer than 3000 characters, _c_v_s_t_a_t_i_c's scanner will fail. Workaround: Use parser mode, or shorten your source lines. 5.5.4 _K_n_o_w_n _P_r_o_b_l_e_m_s _U_s_i_n_g _c_v_s_t_a_t_i_c _i_n _S_c_a_n_n_e_r _M_o_d_e _w_i_t_h _C++ _c_v_s_t_a_t_i_c analyzes C++ source code much more accurately in parser mode than in scanner mode. The following problems are known to occur in scanner mode. They can be avoided by following the workaround suggestions, or by using parser mode. +o _c_v_s_t_a_t_i_c does not do macro expansion, so classes based on macros used to simulate C++ parameterized types are not detected. +o _c_v_s_t_a_t_i_c does not completely handle function calls made through function pointers, in C or C++. In C++, this includes calls to member functions made through object pointers. For example, consider the following code segment: ssssaaaammmmpppplllleeeeffffuuuunnnnccccttttiiiioooonnnn (((()))) {{{{ AAAA ****oooobbbbjjjjeeeecccctttt1111 ==== nnnneeeewwww AAAA(((())));;;; BBBB ****oooobbbbjjjjeeeecccctttt2222 ==== nnnneeeewwww BBBB(((())));;;; oooobbbbjjjjeeeecccctttt1111---->>>>ffffuuuunnnncccc(((())));;;; oooobbbbjjjjeeeecccctttt2222---->>>>ffffuuuunnnncccc(((())));;;; }}}} In this example, _c_v_s_t_a_t_i_c correctly reports that samplefunction() calls func() two times. However, it - 25 - cannot determine that these two function calls are actually made to two different member functions, implemented by two different classes. Similarly, _c_v_s_t_a_t_i_c does not know about the _t_h_i_s pointer. Workaround: Don't try to display full function call trees for C++. Instead use queries like ``Who Calls <function>''or ``Who Is Called By <function>'' which produce meaningful results. +o _c_v_s_t_a_t_i_c does not understand overloaded functions. Workaround: Use the text view for all queries involving overloaded functions. +o C++ allows extensive use of operator overloading, which allows you to write code that can obscure what is really happening in the code. Because _c_v_s_t_a_t_i_c is designed around a pattern matcher, novel constructs produced by overloading operators are not normally detected. Constructs that conform to normal language conventions should normally be found. For example, if A and B are objects, and the ``='' operator has been overloaded to indicate an assignment of the contents of object B to the contents of object A, _c_v_s_t_a_t_i_c should be able to handle this situation. However, if some unusual overloading conventions have been used (say, using ``[]'' to mean a function call), _c_v_s_t_a_t_i_c does not show the same results as the C compiler. Workaround: If you have such code, use string or regular expression searches, or symbol searches to find what you are looking for. +o C++ programs containing templates are not well understood by scanner mode. Workaround: Use parser mode. 5.5.5 _K_n_o_w_n__p_r_o_b_l_e_m_s__U_s_i_n_g__c_v_s_t_a_t_i_c__w_i_t_h__F_o_r_t_r_a_n +o Problem: cvstatic changes case in source files. Workaround: For best results, ignore case: Because the Fortran compilers translate Fortran programs to lower (for Fortran 77) or upper (for Fortran 90) case when analyzing them, you may have trouble selecting a symbol name from the Source View and then using the selection as the target of a query. Therefore, when using the Static Analyzer on Fortran - 26 - sources, it is best to select the Ignore Case option, either through the General Option menu, or persistently through the use of the X resource mechanism thus: cvstatic*ignoreCase: True +o Problem: Fortran file suffixes are ambiguous. Workaround: Tell cvstatic what suffixes you use for which Fortran variant. Both Fortran 77 and Fortran 90 accept files with the the suffixes .f and .F. So, there is no obvious way for the Static Analyzer to tell whether a source file is Fortran 77 or Fortran 90. To indicate that you want a particular suffix to correspond to a particular language, you can set the suffixSource X resource before running cvstatic. For example: *suffixSource: C++.c++ C++.C C++.cxx C++.h C.c Fortran.f Fortran90.F Fortran90.f90 This line in your .Xdefaults file indicates that you want files ending .f to be analyzed as Fortran 77 codes, while files ending .F or .f90 are Fortran 90. You may want to analyze a set of files in which some files ending .f are Fortran 77 while other files with the same suffix are Fortran 90. If so, the only way to distinguish them is for you manually to edit the cvstatic.fileset file and make sure that each filename is followed by the correct driver. For example, these two lines in the fileset file indicate that foo.f is a Fortran 77 file, while bar.f is Fortran 90: ////uuuussssrrrr////ppppeeeeoooopppplllleeee////yyyyoooouuuu////ffffoooooooo....ffff ffff77777777 ////uuuussssrrrr////ppppeeeeoooopppplllleeee////yyyyoooouuuu////bbbbaaaarrrr....ffff ffff99990000 _c_v_s_t_a_t_i_c analyzes Fortran source code much more accurately in parser mode than in scanner mode. The following problems are known to occur in scanner mode. They can be avoided by following the workaround suggestions, or by using parser mode. +o _c_v_s_t_a_t_i_c occasionally misses function calls and other statements that directly follow an _i_f statement on the same line. - 27 - +o _c_v_s_t_a_t_i_c uses a pattern matching approach. This approach does not allow the tool to detect the irregular use of spaces within Fortran symbols, even though these are allowed by the Fortran compiler. For example, the Fortran compiler accepts the statement: ssssuuuubbbb rrrroooouuuuttttiiiinnnneeee mmmmyyyy 1111ffffuuuunnnncccc ttttiiiioooonnnn as if it were written: ssssuuuubbbbrrrroooouuuuttttiiiinnnneeee mmmmyyyyffffuuuunnnnccccttttiiiioooonnnn _c_v_s_t_a_t_i_c does not handle such conventions. Workaround: None in scanner mode. Silicon Graphics strongly suggests changing such code to use a more readable coding style. +o _c_v_s_t_a_t_i_c does not support the use of Fortran keywords for uses other than their intrinsic function. For example, _c_v_s_t_a_t_i_c always recognizes word ``if'' as starting a conditional statement. Programs that use ``if'' as a variable or function name are not analyzed correctly. Workaround: None in scanner mode. Silicon Graphics strongly suggests changing such code to use a more readable coding style. +o In some situations, _c_v_s_t_a_t_i_c can mistake references to arrays as function calls. This is particularly true when the Fortran code relies on include files to declare arrays, common blocks, and so on. _c_v_s_t_a_t_i_c does not analyze header files at the point at which they occur, but simply adds them to the list of files to be analyzed. This contributes greatly to the speed of _c_v_s_t_a_t_i_c, but means that _c_v_s_t_a_t_i_c does not have various type declarations available to it. Because Fortran arrays cannot be differentiated from function calls without a declaration, _c_v_s_t_a_t_i_c identifies arrays not defined in the file in which they are referenced as function calls. Workaround: Use the Results Filter to exclude ``external'' functions. This limits all queries to those functions actually defined in the fileset. Excluding external functions hides all array references erroneously identified as function calls, but also hides all calls to library functions, intrinsic functions, or other routines declared outside the - 28 - fileset. 5.5.6 _K_n_o_w_n__P_r_o_b_l_e_m_s__U_s_i_n_g__c_v_s_t_a_t_i_c__i_n__P_a_r_s_e_r__M_o_d_e Sometimes the General query "Where Symbol Used" fails to report some call sites, if the target of the query was a function. WorkAround: Use the Function query "Who Calls" or "Where Function Used" to get a complete list of places wehre the target function is called or otherwise used. +o The query Where Type Used may return duplicate results in C and C++ programs. For example, asking Where Type Used Foo will produce two copies of the result showing the definition of the symbol FFFFoooooooo ffff;;;; If one of these locations is shown without a function field and one is shown with a function, the latter is correct. Workaround: If you are explicitly looking for definitions, use the queries List Data of Type or List Functions of Type instead. Otherwise, just ignore the duplications. +o The query Where Type Used is confusing about pointers in C and C++. If you ask Where Type Used about a user-defined type named Foo, the query will display all uses of Foo, including uses of types like Foo*, Foo**, Foo[], etc. But if you ask Where Type Used about a built-in type like void or char, the query will display only uses of that exact type. Workaround: Query explicitly about typenames like void*, char**, etc, that contain no user-defined typenames. +o Queries on "integer" and "real" in fortran don't work. Fortran reports integer types as having typenames I*4 and I*8, real types with typenames R*4, R*8, complex types with typenames CM*8 and CM*16, and logical types as L*4. Workaround: To inquire about uses and declarations with these types, enter I*4 (or whatever) into the target - 29 - field instead of "integer". +o Mismatched member function declarations and definitions are not recognized by _c_v_s_t_a_t_i_c'_s parser. The parser runs into trouble processing a member function if the signature of its declaration and definition are not identical. For example, if the code contains something like this: ttttyyyyppppeeeeddddeeeeffff iiiinnnntttt**** iiiinnnnttttppppttttrrrr;;;; ccccllllaaaassssssss AAAA {{{{ ppppuuuubbbblllliiiicccc:::: AAAA ((((iiiinnnntttt **** iiii))));;;; }}}};;;; AAAA::::::::AAAA ((((iiiinnnnttttppppttttrrrr iiii)))) {{{{ }}}} the parser will print the error message "no record for method A::A?" and terminate processing of the file. Workaround: analyze code like this in scanner mode, or change the type signatures so that the definition and declaration match. +o _c_v_s_t_a_t_i_c's parser mode is better at building a new database than at modifying an existing one. If you build a parser-mode database and then change a file and reparse it, the database will grow each time you rescan the file. Not all space is reclaimed. Additional arcs may appear in the Call Tree view representing defunct call site information. Workaround: After a few files are modified and re- analyzed, it is best to use Force Scan to rebuild the entire parser-mode database. For a large code base that is slow to parse, you can use the -batch flag to rebuild the database overnight. +o Functions generated by templates are recognized and displayed by _c_v_s_t_a_t_i_c, but it treats them as external functions: functions that are declared or used within the fileset but are not defined there. Consequently, they do not appear in the results of the ``Query List All Functions''. Workaround: Use specific queries about these functions, like ``Where Function Called'', or add them manually to Call Tree graphs. - 30 - +o The function "main" appears in the list of Functions Not Called, if it is not called explicitly from the source code. ("main" is rarely called explicitly.) Workaround: You can add the function "main" manually to any graphical display of functions. +o Graphical display of a single member function called through derived classes is incomplete. If a C++ member function FFFFoooooooo::::::::FFFFuuuunnnncccc is called through classes derived from the ccccllllaaaassssssss FFFFoooooooo, each derived function FFFFuuuunnnncccc will appear as a separate function in the Text View list of functions. However, only one node will appear for FFFFuuuunnnncccc in the Call Tree View. Workaround: To see the full list of definitions and calls of FFFFuuuunnnncccc, use Text Mode. If you double click on the definition of one of the derived FFFFuuuunnnnccccs, you will navigate either to the definition of the function (if you click on the version in FFFFoooooooo), or to the definition of the derived class through which FFFFuuuunnnncccc was called. +o If you are analyzing C++ code in which multiple non- member functions have the same name, _c_v_s_t_a_t_i_c will think they are all the same function with one definition and several declarations. Workaround: You can get to the definitions by using the ``Where Defined'' and ``Where Declared'' queries on functions. +o When you first bring up _c_v_s_t_a_t_i_c, if you switch the view from Text View to a graph view before building the parser database and doing your first query, the graph may incorrectly display as empty. Workaround: Stay in Text View to perform your first query, and then switch to whichever graph view you wish. Or, if you have already brought up _c_v_s_t_a_t_i_c in a graph view and built the database, hit ``Rescan'' in the Admin menu, and then redo your query. 5.6 _W_o_r_k_S_h_o_p__C_+_+__B_r_o_w_s_e_r +o The _C++ _B_r_o_w_s_e_r currently works only on files in the parser fileset. So if you have a fileset which has only files in the scanner fileset, the browser will not work. To generate the database, you have to put files in the parser fileset and issue a rebuild in _c_v_s_t_a_t_i_c. Once the database is created you can use Browser to - 31 - examine the C++ classes. +o When using the C++ Browser, if you make changes to the code in the files that are present in the fileset, the changes will not be reflected in the information presented by the C++ Browser until you issue a Rescan command in _c_v_s_t_a_t_i_c, as follows: * Make your changes. * Exit the C++ Browser (but not cvstatic). * Issue a FFFFoooorrrrcccceeee SSSSccccaaaannnn from the cvstatic AAAAddddmmmmiiiinnnn menu. * Restart the browser by selecting AAAAddddmmmmiiiinnnn/CCCC++++++++ BBBBrrrroooowwwwsssseeeerrrr menu in cvstatic. Incident 186990. +o When using the C++ browser, if you create and close (or quit) the Class Graph or Call Graph windows many times, some times you may find that it will make the tool core dump or exit with X errors. This is due to some known defects in deletion of widgets in Xm and Sgm. Incident 204472. +o Duplicate class definitions encountered in your files in the parser fileset will end up as a single class with accumulating members from both the definitions. This happens when the file defining the class is included from two different paths or there are two genuine class definitions for the same class name in your fileset. Incident 206922. +o If you use typedefs, and use it to give alternate names to classes (as in _t_y_p_e_d_e_f _c_l_a_s_s _A _B;) - you may that the Build Window shows some warnings about not finding the class B and that the information collected about the usage of class A will be missing many of the references through its typedef B. This kind of typedef is more commonly found in template code. There is no good workaround currently, other than not using the typedef in question. Incident 217830. - 32 - +o If you use typedefs, and use it inconsistently in declaring and defining class members (as in the following example), you will find that information regarding those members is either missing or faulty. The workaround is to use the same prototype at the point of definition as at the point of declaration. ttttyyyyppppeeeeddddeeeeffff iiiinnnntttt IIIINNNNTTTT;;;; ccccllllaaaassssssss AAAA {{{{ vvvvooooiiiidddd ffffoooooooo ((((IIIINNNNTTTT))));;;; }}}};;;; vvvvooooiiiidddd AAAA::::::::ffffoooooooo ((((iiiinnnntttt vvvvaaaallll)))) ............ //////// ggggeeeettttssss wwwwaaaarrrrnnnniiiinnnngggg,,,, aaaannnndddd iiiissss mmmmiiiissssssssiiiinnnngggg //////// ffffrrrroooommmm ssssttttaaaattttiiiicccc aaaannnnaaaallllyyyyssssiiiissss iiiinnnnffffoooo.... Incident 184455. +o Usage information for template classes is managed only on a per-instantiation basis. If you use templates in your code, then each instantiation, and the template itself, will show up as classes in the C++ Browser. For instance, if you have a template class Foo<T>, then there will be a class called FOO<T> and classes FOO<A>, FOO<B> etc., for the template definition prototype of FOO and its instantiations with A, B, etc., respectively. And the usage information on FOO<T> currently shown is not the amalgamation of usage information on its instantiations FOO<A>, FOO<B>, etc. +o Be careful about overwriting man pages which are generated using the automatic class man page generation facility. When you generate a manpage for a class, through the C++ browser, you get a skeleton, in which you have to fill in all the descriptions. Please remember that if you change the class and generate a new man page for that class again, your changes to the file will be lost if you ignore the man page overwrite warning dialog. To avoid losing your changes to a manpage file generated by C++ Browser do the following: * Move the existing manpage out of the way to some other file. * Generate the new (skeleton) man page. * Merge the changes from the saved file to the new man page generated by the C++ Browser. - 33 - +o When you use an application which allocates lot of colors in the default color map and then use cvstatic or C++ browser to bring up graphs, you might get all black nodes with un-readable text. The only known workaround to this problem is to kill the X server and login again. Be sure that you bring up cvstatic before you bring up the offending application. This problem has been seen with viewing books which have full color pictures. 5.7 _W_o_r_k_S_h_o_p__P_e_r_f_o_r_m_a_n_c_e__A_n_a_l_y_z_e_r +o On IRIX 6.2, certain large programs will use a linker- feature called the multi-got feature. The performance analyzer will issue an error message if this occurs, and you should contact customer support for an updated version of the analyzer. +o On IRIX 6.2, Ideal-time experiments are not supported for corded n32 and n64 executables. The performance analyzer will issue an error message if this occurs. +o Important: You should remove any old instrumentation cache directories, _e._g., /_u_s_r/_t_m_p/_c_v_i_n_s_t_r_l_i_b, prior to using this version of WorkShop: %%%% rrrrmmmm ----rrrrffff ////uuuussssrrrr////ttttmmmmpppp////ccccvvvviiiinnnnssssttttrrrrlllliiiibbbb +o WS 2.5.1 MP linpackd CPU time and Ideal-time show bogus times on 5.3 (Incident 321828) +o On IRIX 6.1 on R8000 systems, _c_v_p_e_r_f and _p_r_o_f report somewhat different cycle counts and ideal-time, from the same counts data. The instruction counts reported match. Each is internally consistent, but they differ because they are using somewhat different machine models for the computation. Since the time and cycles are idealized in both cases, the discrepancy may be ignored; both will correctly show the places in the code where the most time is spent (Incident 292498). +o Running the Bottleneck and Total-Time experiments significantly slow the execution of some programs because of the time it takes to unwind the stack. +o _c_v_p_e_r_f is not backwards-compatible with experiments recorded on prior WorkShop releases, and will typically core dump on them. - 34 - +o Instrumenting _l_i_b_c with the PC-sampling option will fail in IRIX 5.3 because there is not enough address space left for text and data sections (Incident #223912). These experiments work in IRIX 6.2. Workaround: There is no workaround for this problem on IRIX 5.3. +o The Performance Analyzer may fail on experiments on executables that load very many DSOs (more than several hundred) (Incident #290637). +o Ideal-time and CPU-time experiments on n32 executables that do multiple dlopen/dlsym/dlclose operations may fail (Incident #291951). +o Ideal-time and CPU-time experiments on executables that use Load-linked/ Store-conditional instructions may fail, because the instrumenation may insert memory references between the instructions (Incident #291777). +o Memory leak experiments on programs that fork may produce misleading data. For example, a child process may free a block allocated in the parent, which will appear as a bad free. (Incident #202710) +o During data collection, the collector, _c_v_m_o_n, might run out of disk space. In this case, it posts an error pop-up to the effect of ``bead write failed: no space left on device''. Workaround: Kill the debugger, free up sufficient space on the disk, and start the run again. +o The Performance Analyzer does not support COFF executables. +o The Performance tools can collect a great deal of data, and easily fill a disk. For typical programs, basic- block sampling can collect between 0.25 and 2 Mbytes of data at each sample point. PC sampling data can amount to between 0.25 and 6 Mbytes for each sample. Workaround: Use care in specifying how many samples you take to avoid this problem. Be especially careful in using Pollpoint sampling; it should normally be used collecting only callstacks, not function counts, basic-block counts, or PC sampling data. Sampling is not expensive in tracing experiments. - 35 - +o The Main View has a notion of a default trap that is a stop trap if data collection has not been enabled in the Performance Panel (where ``enabled'' means after _A_c_c_e_p_t or _O_K was clicked), and a sample trap if it has been enabled. This setting is independent of the default trap set in the Trap Manager. Clicking in the margin of the MainView source window sets or clears the MainView default trap, and does not affect a trap of the other type. +o _m_a_l_l_o_c/_f_r_e_e traces can be quite voluminous and difficult to process in Heap View. When doing _m_a_l_l_o_c/_f_r_e_e tracing, be careful to design your experiments to exercise only those regions of your code that are problematic, and minimize the amount of trace data collected. It is difficult to estimate the volume of data produced. Each event writes 20 to 80 bytes, or more, depending on the depth of the callstack at the time of the call. A 10-minute experiment with the WorkShop Performance Analyzer wrote 140 Mbytes of trace data. Reading this experiment took ~12 minutes on a 256-MB Onyx machine. +o The WorkShop Performance Analyzer can record experiments on MP FORTRAN programs, but there are a number of anomalies in the displayed data that require explanation. For all FORTRAN MP compilations, parallel loops within the program are represented as subroutines with names relating to the source routine in which they are embedded. The naming conventions for these subroutines are different for 32-bit and 64-bit compilations For example, in the linpack benchmark, most of the time spent is in the routine _D_A_X_P_Y, which can be parallelized. In a 64-bit MP version, the routine has the name "DAXPY", but most of that work is done in the MP routine named "DAXPY.PREGION1". In a 32-bit version, the _D_A_X_P_Y routine is named "daxpy_", and the MP routine "_daxpy_519_aaab_". In both cases, for an ideal time experiment on a uniprocessor -_g run, the inclusive and exclusive function level times are correct. The source annotations, however, behave differently and incorrectly in most cases. In 64-bit source annotations, the exclusive time is correctly shown for each line, but the inclusive time for the first line of the loop (_d_o statement) includes the time spent in the loop body. This same time appears - 36 - on the lines comprising the loop's body, in effect, representing a double-counting. When used in conjunction with WorkShop Pro MPF's Parallel Analyzer View, the loop performance data will incorrectly also reflect the double counting, and the time will not be always shown as a percentage: whenever it would exceed 100%, it is shown as <_n/_a>. The numerical time value shown reflects the double counting. In 32-bit source annotations, the exclusive time is incorrectly shown for the line comprising the loop's body, as the line-level data for the loop-body routine ("_daxpy_519_aaab_") does not refer to proper lines. If the program was compiled with the -_m_p__k_e_e_p flag, the line-level data should refer to the temporary files that are saved from the compilation, but the temporary files do not contain that information, so no source or disassembly data can be shown. The disassembly data for the main routine does not show the times for the loop-body. If the 32-bit program was compiled without -_m_p__k_e_e_p, the line-level data for the loop-body routine is incorrect, with most lines referred to line 0 of the file, and the rest to other lines at seemingly random places in the file. Consequently, spurious annotations will appear on these other lines. Disassembly correctly shows the instructions, and their data, but the line numbers shown are wrong. MPF's Parallel Analyzer correctly shows the loop data in most cases, but the same incorrect line numbers can cause data relating to one loop to show up in other parts of the program. This reflects what is essentially the same double-counting problem as seen in 64-bits, but the extra counts go to other places in the file, rather than the first line of the loop. NNNNOOOOTTTTEEEE:::: We recommend against using the -_m_p__k_e_e_p flag. +o For MP experiments, switching between threads will cause the calipers to change to points valid for the new thread. Switching back may use different points, and therefore, show different numbers. Set the calipers manually after switching to ensure proper placement. +o For MP experiments, stopping one thread can cause the notion of time in other threads to get confused. It is not recommended. +o The inclusive data shown in _c_v_p_e_r_f represents the instruction counts and/or PC sampling data summed over - 37 - the routine and those routines that it calls. The computations are based on a heuristic that assumes that all calls from all callers are equivalent. For programs where this heuristic is not applicable, for example, where one call to a matrix-multiply routine is for matrices of order four, while a second call is for matrices of order 100, the cumulative data may be misleading. +o Line-level data assigns a value to a line equal to the highest value for any instructions attributed to that line. It can be confusing, because compiler optimizations often rearrange the code in ways that is non-obvious. Looking at a disassembly view of the data can help. +o Line-level data from assembler routines can be misleading. The symbol table often has instructions attributed to the wrong source line. +o In some cases, line number data for a C++ routine that uses inline virtual functions defined in an included file gets the line numbers incorrectly displayed as if they came from the file in which the defining file is included. This causes incorrect line-level data to show at the lines in the original file. The Disassembly View in _c_v_p_e_r_f shows performance data for each instruction, and may help disambiguate attribution. +o _c_v_p_e_r_f filters out nodes and arcs that were not executed during the current caliper setting. This feature can lead to confusing displays, where nodes that are known to be in the program do not appear. Workaround: The Preferences menu can be used to disable the filtering. +o _c_v_p_e_r_f does not support live performance experiments. That is, you should not bring up _c_v_p_e_r_f until the experiment is over. If you do, it will not update as more data is recorded. +o Performance experiments on multi-process applications can occasionally be unreliable if sample events are quickly preceded by process creation, or succeeded by process termination. +o Heap View scrolls poorly and blocks flash on large experiments. Its functionality has been mostly subsumed by Leak View, Malloc View, and Malloc Error - 38 - View. (Incident# 67628) +o Callstacks may be wrong in MP experiments. (Incident# 189826) +o Pollpoint sampling will fail if the target process forks, and the parent exits before the child. (Incident #186429) 5.8 _W_o_r_k_S_h_o_p__T_e_s_t_e_r 5.8.1 _W_o_r_k_S_h_o_p__T_e_s_t_e_r__L_i_m_i_t_a_t_i_o_n_s +o Instrumented programs can increase in size by a factor of 2X to 5X. However, DSO caching and sharing alleviates this problem greatly. +o Block and branch coverage are at the assembly language level. They can provide useful metrics and do map back to the source lines. Note that several assembly branch instructions may map back to the same source line. To see the C, C++, and Fortran source level blocks and branches, use _c_v_c_o_v _l_s_s_o_u_r_c_e. +o Compilation with the debug flag -_g builds assembly language branches and blocks that can never be executed. This adversely affects overall coverage. By compiling with "O1" (the default), some of the unused assembly branches and blocks are not built. This gives a more accurate block and branch coverage metric. Function and arc coverage are unaffected by compile flags. +o C++ in-line functions are not counted as functions unless they are out-of-lined by the compiler. +o By default, arguments of functions are not displayed in query results. This can be confusing for C++ overloaded functions because there is no way to distinguish between them. To work around this problem, use the -_a_r_g option to show full function signatures. +o The default size of the SourceView annotation canvas may not be large enough to hold very large counts. The resource name for setting canvas width for SourceView is "canvasWidth". The default value is 60. The user can modify this width by modifying the following resource found in the Cvxcov app-defaults file, "Cvxcov*test*testData*canvasWidth". - 39 - +o _T_e_s_t_e_r currently uses object level instrumentation. This has several advantages: ((((1111)))) CCCCoooovvvveeeerrrraaaaggggeeee ddddaaaattttaaaa ccccaaaannnn bbbbeeee oooobbbbttttaaaaiiiinnnneeeedddd wwwwiiiitttthhhhoooouuuutttt aaaacccccccceeeessssssss ttttoooo tttthhhheeee ssssoooouuuurrrrcccceeee ccccooooddddeeee.... ((((2222)))) CCCCoooovvvveeeerrrraaaaggggeeee ddddaaaattttaaaa ccccaaaannnn bbbbeeee oooobbbbttttaaaaiiiinnnneeeedddd wwwwiiiitttthhhhoooouuuutttt rrrreeeeccccoooommmmppppiiiillllaaaattttiiiioooonnnn////rrrreeeebbbbuuuuiiiilllldddd.... ((((3333)))) TTTThhhhiiiissss ssssuuuuppppppppoooorrrrttttssss CCCC,,,, CCCC++++++++,,,, aaaannnndddd FFFFoooorrrrttttrrrraaaannnn wwwwiiiitttthhhhoooouuuutttt ssssppppeeeecccciiiiaaaallll llllaaaannnngggguuuuaaaaggggeeee ssssuuuuppppppppoooorrrrtttt ffffrrrroooommmm tttthhhheeee ccccoooommmmppppiiiilllleeeerrrrssss.... This has several disadvantages: ((((1111)))) BBBBlllloooocccckkkk aaaannnndddd bbbbrrrraaaannnncccchhhh ccccoooouuuunnnnttttssss aaaarrrreeee aaaatttt tttthhhheeee aaaasssssssseeeemmmmbbbbllllyyyy llllaaaannnngggguuuuaaaaggggeeee lllleeeevvvveeeellll.... ((((2222)))) MMMMoooorrrreeee ddddeeeettttaaaaiiiilllleeeedddd ccccoooovvvveeeerrrraaaaggggeeee rrrreeeeqqqquuuuiiiirrrreeeessss kkkknnnnoooowwwwlllleeeeddddggggeeee ooooffff tttthhhheeee llllaaaannnngggguuuuaaaaggggeeee sssseeeemmmmaaaannnnttttiiiiccccssss.... FFFFoooorrrr eeeexxxxaaaammmmpppplllleeee,,,, hhhhaaaassss eeeevvvveeeerrrryyyy ppppoooossssssssiiiibbbblllleeee ccccaaaasssseeee iiiinnnn aaaa mmmmuuuullllttttiiiipppplllleeee ccccoooonnnnddddiiiittttiiiioooonnnnaaaallll ffffiiiirrrreeeedddd dddduuuurrrriiiinnnngggg tttteeeessssttttiiiinnnngggg.... +o _W_e_a_k _e_x_t_e_r_n_a_l_s refer to an aliasing facility used by the compilation environment. For example, while user programs may call the function "read", the actual function name in the C library that implements "read" is "_read". In this case, "read" is a weak external for "_read". If the user CONSTRAINS coverage on either name, _T_e_s_t_e_r will report the results correctly. However, _T_e_s_t_e_r will choose the name used to implement the function, in this case "_read". +o -_f_u_n_c__p_a_t_t_e_r_n is a function pattern used in the following _c_v_c_o_v subcommands: _l_s_b_l_o_c_k, _l_s_b_r_a_n_c_h, _l_s_f_u_n, _l_s_t_r_a_c_e. Currently, only the following "patterns" are matched. """"DDDDSSSSOOOO::::****"""" -------- aaaallllllll ffffuuuunnnnccccttttiiiioooonnnnssss iiiinnnn aaaa DDDDSSSSOOOO DDDDSSSSOOOO::::ffffuuuunnnnccccttttiiiioooonnnn____nnnnaaaammmmeeee -------- ssssppppeeeecccciiiiffffiiiicccc ffffuuuunnnnccccttttiiiioooonnnn iiiinnnn aaaa DDDDSSSSOOOO ffffuuuunnnnccccttttiiiioooonnnn____nnnnaaaammmmeeee -------- ffffuuuunnnnccccttttiiiioooonnnn____nnnnaaaammmmeeee iiiinnnn mmmmaaaaiiiinnnn pppprrrrooooggggrrrraaaammmm aaaannnndddd ddddssssoooo''''ssss <<<< ooooppppttttiiiioooonnnn nnnnooootttt uuuusssseeeedddd >>>> -------- aaaallllllll ffffuuuunnnnccccttttiiiioooonnnnssss aaaarrrreeee iiiinnnncccclllluuuuddddeeeedddd iiiinnnn qqqquuuueeeerrrryyyy +o Sharing of the WorkShop Performance Analyzer performance experiment data is supported in _c_v_c_o_v but not in _c_v_x_c_o_v of this release. +o Output of query results to a printer is not supported in this release. As a workaround, the user can save query results to a file, and then send that file to a printer. +o Experiment data for test sets/test groups cannot be moved/copied (mv, cp) without invalidating the data. Leaf tests can be moved/copied. +o Both the _l_s_t_r_a_c_e feature (argument tracing) and the _l_s_s_o_u_r_c_e feature (mapping block counts to actual - 40 - source) require the code to be compiled with -_g. A notable exception to this is return value tracing which can trace the return value on functions that are not compiled with -_g (e.g., _l_i_b_c functions). +o _c_v_c_o_v requires that all instrumentation be performed before the experiment is run. This includes instrumentation for programs that are forked/exec'ed or sproc'ed. _c_v_m_o_n is the program used by _c_v_c_o_v to monitor the experiment. If _c_v_m_o_n encounters child processes, and the coverage experiment includes any executables other than the main program, then _c_v_m_o_n will instrument the executables for the child processes "on the fly". _c_v_c_o_v will not process coverage for these "on the fly" instrumented executables, because _c_v_m_o_n has not used the correct coverage instrumentation criteria. This can cause performance and space overhead. +o IRIX 5.1 and later binaries are supported (no support for IRIX 4.0.X binaries) including shared and nonshared. +o Instrumentation criteria ccccoooouuuunnnnttttssss must at least include ----bbbbbbbbccccoooouuuunnnntttt. For example, if user want to test function pointers the instrumentation file must contain the following line, CCCCOOOOUUUUNNNNTTTTSSSS ----bbbbbbbbccccoooouuuunnnnttttssss ----ffffppppccccoooouuuunnnnttttssss +o The current model for running instrumented programs requires that a separate process (_c_v_m_o_n) monitor the programs that are undergoing coverage analysis. This requires existing test scripts to be modified in the following manner: oooolllldddd ssssccccrrrriiiipppptttt:::: #### pppprrrrooooggggrrrraaaammmm aaaarrrrgggg1111 aaaarrrrgggg2222 nnnneeeewwww ssssccccrrrriiiipppptttt:::: #### ccccvvvvccccoooovvvv mmmmkkkktttteeeesssstttt ----ccccmmmmdddd """"pppprrrrooooggggrrrraaaammmm aaaarrrrgggg1111 aaaarrrrgggg2222"""" ----tttteeeessssttttnnnnaaaammmmeeee tttteeeesssstttt #### ccccvvvvccccoooovvvv rrrruuuunnnntttteeeesssstttt tttteeeesssstttt +o There is potentially a large amount of data that can be captured when running multiple tests for large programs. There are several options to the _r_u_n_t_e_s_t command that help manage this data. The -_n_o_a_r_c option is used to eliminate the capture of arc data in the experiment result (e.g., arc AB is equivalent to function A calls function B from line X). This significantly reduces the amount of overall count - 41 - information for the test coverage result. The -_r_m_s_u_b option is used to retain the overall results for the top level test set or test group, not for the individual subtests. There are several interactions of the -_r_m_s_u_b and -_s_u_m options worth noting. If the -_r_m_s_u_b option is used, a subsequent "runtest" using the -_s_u_m option will not accumulate the counts data for these two runs. In this case only the second run will be in the top level test set/test group. The -_s_u_m option will sum up data only according to the count data that is in all the subtests currently and does not use the information in the top level test set or test group. When using the -_s_u_m and -_r_m_s_u_b options together, the count data will be accumulated and the subtest data will be deleted. The -_c_o_m_p_r_e_s_s option is used to compress experiment database using standard utility _c_o_m_p_r_e_s_s. The -_b_i_t_c_o_u_n_t option is used to convert experiment database to 1-bit-per-count format in recording experiment so that it will save disk space up to 32 times. However, count number for basic blocks and branch coverage information will be lost. +o Source highlighting for statement that cover multiple lines only highlights the last line. This is due to a limitation in symbol table data generated by the compiler. For example, in the following source statement only the second line will be highlighted: pppprrrriiiinnnnttttffff((((""""TTTThhhhiiiissss iiiissss aaaa tttteeeesssstttt ffffoooorrrr %%%%ssss aaaatttt %%%%dddd"""",,,, 0000 tttteeeessssttttnnnnaaaammmmeeee,,,,wwwwhhhhiiiicccchhhhDDDDrrrriiiivvvveeee))));;;; +o If the DSO cache directory has been removed, all the existing experiments may be invalid and _T_e_s_t_e_r may not work. 5.8.2 _W_o_r_k_S_h_o_p__T_e_s_t_e_r__B_u_g_s +o Programs that use _a_r_g_v[_0] to build hardcoded filenames get confused by the renamed instrumented program (e.g., <program> becomes <program_Instr>). - 42 - 5.9 _W_o_r_k_S_h_o_p__E_n_v_i_r_o_n_m_e_n_t +o If the colors of your WorkShop windows look too dark to read or conversely if they look completely washed out, there may be a discrepancy between the gamma value you are using and the value your X server is using. The default value of gamma on installation is 1.7 but users running X programs may prefer a value of 1.0. Workaround: If you change your gamma value, by running the _g_a_m_m_a program (installed with _e_o_e_2._s_w._g_l_t_o_o_l_s), restart your X server. +o When starting up WorkShop, if you see the messages ////uuuussssrrrr////ssssbbbbiiiinnnn////ttttttttsssseeeessssssssiiiioooonnnn:::: CCCCaaaannnn''''tttt iiiinnnniiiitttt ttttyyyyppppeeee ddddaaaattttaaaabbbbaaaasssseeee.... ////uuuussssrrrr////ssssbbbbiiiinnnn////ttttttttsssseeeessssssssiiiioooonnnn:::: eeeexxxxiiiittttiiiinnnngggg WWWWaaaarrrrnnnniiiinnnngggg:::: ttttttttsssseeeessssssssiiiioooonnnn:::: ssssiiiigggg____hhhhaaaannnnddddlllleeeerrrr:::: NNNNoooo cccchhhhiiiilllldddd pppprrrroooocccceeeesssssssseeeessss ////uuuussssrrrr////ssssbbbbiiiinnnn////ttttttttsssseeeessssssssiiiioooonnnn:::: CCCCaaaannnn''''tttt iiiinnnniiiitttt sssseeeerrrrvvvveeeerrrr.... ttttttttsssseeeessssssssiiiioooonnnn:::: CCCCaaaannnn''''tttt iiiinnnniiiitttt ttttyyyyppppeeee ddddaaaattttaaaabbbbaaaasssseeee.... ttttttttsssseeeessssssssiiiioooonnnn:::: eeeexxxxiiiittttiiiinnnngggg WWWWaaaarrrrnnnniiiinnnngggg:::: ttttttttsssseeeessssssssiiiioooonnnn:::: ssssiiiigggg____hhhhaaaannnnddddlllleeeerrrr:::: NNNNoooo cccchhhhiiiilllldddd pppprrrroooocccceeeesssssssseeeessss ttttttttsssseeeessssssssiiiioooonnnn:::: CCCCaaaannnn''''tttt iiiinnnniiiitttt sssseeeerrrrvvvveeeerrrr.... TTTTttttuuuuttttiiiillll:::: CCCCaaaannnnnnnnooootttt ooooppppeeeennnn oooouuuurrrr TTTToooooooollllTTTTaaaallllkkkk pppprrrroooocccceeeessssssss iiiidddd ttttttttuuuuttttiiiillll:::: CCCCoooouuuullllddddnnnn''''tttt ccccoooonnnnnnnneeeecccctttt ttttoooo ttttttttsssseeeessssssssiiiioooonnnn sssseeeerrrrvvvviiiicccceeee((((ssss)))).... check if you have the _C_E_P_A_T_H environment variable set. ToolTalk will use the _C_E_P_A_T_H variable for its definition of where the types database are located. WorkShop expects to find them in the default system database, /_e_t_c/_t_t/_t_y_p_e_s._x_d_r. Unsetting this environment variable will fix the startup problem. +o When starting up WorkShop, you may occassionally see the message ////uuuussssrrrr////ssssbbbbiiiinnnn////ttttttttsssseeeessssssssiiiioooonnnn:::: WWWWaaaarrrrnnnniiiinnnngggg:::: ccccoooouuuullllddddnnnn''''tttt aaaaccccqqqquuuuiiiirrrreeee XXXX sssseeeelllleeeeccccttttiiiioooonnnn ToolTalk displays this message when its internal state notes that someone else (i.e. another _t_t_s_e_s_s_i_o_n) has already owned the X selection that it is trying to aquire. This message is harmless and can be ignored. +o The network license mechanism used by WorkShop performs periodic checks to ensure that a license is available. Once obtained, a license is valid for 20 minutes. The license is validated every 10 minutes, and renewed for an additional 20 minutes if all is well. This process requires that WorkShop be actively running to be able to perform these checks. If the tool is unable to check the license server for 20 minutes, the license is lost, - 43 - and the tool must be restarted to get a new license. Therefore, suspending a WorkShop process (using <Ctrl- Z>, for example) for more than a few minutes loses the tool's license. +o The WorkShop environment works with one configuration management system at a time. This affects all users running WorkShop on that machine. +o The default for string data is to display it as a hex address. If you prefer the behavior of showing a string for _c_h_a_r *, you can set ****aaaauuuuttttooooSSSSttttrrrriiiinnnnggggFFFFoooorrrrmmmmaaaatttt to TTTTrrrruuuueeee in your ._X_d_e_f_a_u_l_t_s. This will automatically change the result format from the default to string for _c_h_a_r * and _c_h_a_r <_a_r_r_a_y> expressions in the ExpressionView, VarBrowser, and DataBrowser. +o Customers displaying to non-SGI X displays and having difficulties with ExecutionView startup (a busy cursor that never goes away) should try switching ****eeeexxxxeeeeccccuuuuttttiiiioooonnnnVVVViiiieeeewwww****TTTTeeeerrrrmmmmiiiinnnnaaaallllCCCCoooommmmmmmmaaaannnndddd in /_u_s_r/_W_o_r_k_S_h_o_p/_u_s_r/_l_i_b/_X_1_1/_a_p_p-_d_e_f_a_u_l_t_s/_C_v_m_a_i_n from the _x_w_s_h version to the commented out _x_t_e_r_m version.