Tools

dbx

Known dbx issues and Workarounds

1. Data Collection Problems When dbx is Attached to a Process

   If you attach dbx to a running process without preloading the collector library, libcollector.so, a number of errors can occur.

   • You cannot collect any tracing data: synchronization wait tracing, heap tracing, or MPI tracing. Tracing data is collected by interposing on various libraries, and if libcollector.so is not preloaded, the interposition cannot be done.

   • If the program installs a signal handler after dbx is attached to the process, and the signal handler does not pass on the SIGPROF and SIGEMT signals, profiling data and sampling data is lost.

   • If the program uses the asynchronous I/O library, libaio.so, clock-based profiling data and sampling data is lost, because libaio.so uses SIGPROF for asynchronous cancel operations.

   • If the program uses the hardware counter library, libcpc.so, hardware-counter overflow profiling experiments are corrupted because both the collector and the program are using the library. If the hardware counter library is loaded after dbx is attached to the process, the hardware-counter experiment can succeed provided references to the libcpc library functions are resolved by a general search rather than a search in libcpc.so.

   • If the program calls setitimer(2), clock-based profiling experiments can be corrupted because both the collector and the program are using the timer.

2. dbx might crash while debugging Java code

   If you issue a cd command from within the dbx shell, or set the CLASSPATH environment variable or the CLASSPATHX environment variable, dbx might subsequently crash with a segmentation fault.

   Workarounds:

   • Do not do any of the above.

   • Delete all watches (displays) before doing any of the above.

3. dbx crashes on re-debugging of Java code

   Issuing two debug commands in a row on Java code might cause dbx to crash.

4. dbx throws an exception when debugging application on different J2SE than it was built on

   dbx throws an exception when you debug an application under a different release of the J2SE technology than the version of the J2SE technology under which you built the application.

5. False RUA error reported due to pre-RTC monitoring allocations

   Under unusual circumstances with multithreaded programs, runtime checking (RTC) reports a false RUA error when it detects access to internal thread-related data that were allocated before RTC began monitoring memory allocations. As these circumstances are part of normal thread switching behavior, these false RUA reports can safely be ignored by using the dbx suppress command.

dbx Limitations and Incompatibilities

Oracle Solaris Studio 12.3 dbx has the following limitations:

• It is not possible to attach to a running process from your .dbxrc file. A .dbxrc file should not contain commands that execute your code. However, you can put such commands in a file, and then use the dbx source command to execute the commands in that file.

• dbx incorrectly demangles pointer to member functions compiled with the -compat=4 option. This problem does not occur for the -compat=5 option.

  ---

  Note - The -compat=4 option was removed in this release. See C++ Compiler for details.

  ---

• On SPARC V9 (-m64) systems, use of the call command or printing function calls is not working with nested small structure as an argument or as a return value.

• Using older copies of libC.so.5 or libC.so.4 may cause problems for dbx in the area of C++ exceptions. Warning messages about bad stabs and unhandled exceptions may result.

  Workaround: Install the latest libC.so.5 on all systems.

• Fortran users should compile with the -stackvar option to take full advantage of runtime checking.

• Some programs may not work properly with the -stackvar option. In such cases, try the -C compiler option, which will turn on array subscript checking without RTC.

• Follow fork may be unreliable for multithreaded applications.

• Use of the call command or printing function calls might cause deadlock situations with multithreaded applications.

• Do not use the fix and continue feature of dbx to change a header file if the file was part of a pre-compiled header (PCH) collection.

• The dbx command line interpreter is an older version of the Korn shell (ksh) that does not support Code Set Independence (CSI). Multi-byte characters can be misinterpreted when typed on the dbx command line.

• The following features of dbx are not available on the Linux OS:

  • Fix and continue

  • Performance data collection

  • Breakpoints on the following events:

    • fault

    • lastrites

    • lwp_exit

    • sysin

    • sysout

    • sync

    • throw

  • Java debugging

  • Debugging 32–bit programs, unless you start dbx with the -x exec32 option.

• The following problems may occur when debugging programs on Linux platforms:

  • dbx cannot follow forked processes on Linux platforms or change to a new program when exec() is called

  • The pipe operator in the Korn shell is limited on Linux platforms. Any dbx command that needs to access the target process does not work as part of a pipeline. For example, the following command is likely to cause dbx to hang:

    where | head -1

    Workarounds:

    • Type Ctrl-C to display a new dbx prompt.

    • dbx caches a lot of information, so for the above example, the following sequence of commands works:

      where
      where | head —1

  • If a program uses clone() to implement its own style of threads, then thread support in dbx does not identify threads correctly.

    Workaround:

    Use libthread.so rather than clone().

  • The threads library in the Linux OS uses SIGSTOP signals as part of its internal mechanism. Normally dbx hides these signals from you, and allows you to monitor genuine SIGSTOP signals from other sources. Occasionally the Linux OS uses SIGSTOP in an unexpected way and dbx interprets a system-generated SIGSTOP as a user-generated SIGSTOP.

    Workaround:

    Use the ignore command to tell dbx not to catch SIGSTOP signals.

  • Sometimes a thread exits, but the Linux OS does not report the exit to dbx.

    When a thread exits and the exit is not reported, dbx waits for an event that will never happen and does not display a new prompt. This situation is most likely to occur after you have given a cont command in dbx, but it can also happen after the step up command, step command, next command, and other commands.

    Workarounds:

    • Sometimes typing Ctrl-C causes dbx to stop waiting and display a new prompt.

    • If Ctrl-C does not work, exit dbx and restart it.

• dbx does not support the following features for the GNU C and C++ compilers:

  • VL array

  • Exception handling

  • OpenMP

  • RTTI

  • Template definition

  • Default argument

  • using directive

  • friend

• Some issues exist for dbx on Oracle Linux 6:

  • Indirect reference symbols used in system libraries can sometimes cause dbx to set breakpoints at the reference rather than the actual function.

  • When debugging code compiled with gcc 4.4.4 compilers:

    • dbx might hang when printing a variable length array.

    • dbx is unable to see local variables when stopped at the very end of a function (the } line).

    • dbx does not see macros defined using the -D compiler option.

Performance Analyzer

This section describes known problems with the Performance Analyzer tool.

• Sometimes the Callers-Callees tab shows a truncated metric value.

• The icache stall time might be overestimated on SPARC T4 processors.

• The OpenMP Wait metric for OMP tasks and OMP parallel regions do not add up to the OpenMP Wait metric for <Total> because any profiling packets that arrive before the first parallel region entry do not get counted as OMP Wait time for any task or region, but do get counted in the total.

• Adding and dropping experiments is not always properly handled; the workaround is to load all experiments initially, and filter to exclude the ones you would want to drop.

• Moving tabs does not always work properly.

• Multiple selection of items in tabs does not always work properly.

• Analyzer sometimes hangs at SummaryDisp.updateSummary(SummaryDisp.java:249)

• The Summary tab is not updated when a selection is made in the Source-Disassembly tab.

• Highlighting in the margin of the Source tab may not be shown even when there are non-zero metrics.

• The Show/Hide/API-only functionality for shared objects does not always work properly in conjunction with filtering. This issue also occurs when using er_print to view experiment data.

• The Apply button in the General tab of the Manage Filters dialog box does not always apply changes. Pressing Apply more than once may help. A more reliable workaround is to access filters from the context menus in the Timeline, Threads, and CPUs data tabs.

• In the Timeline tab, Threads and CPUs might not be shown in numerical order.

collect Utility

This section describes known problems with the collect utility and data collection.

• For some optimized codes, the stack unwind on Sandy Bridge machines is sometimes incorrect.

• Because of an implementation change for locking algorithms in JDK 1.7, synchronization tracing on Java programs double-counts all Java synchronization events. The workaround is to divide the reported values by two.

• On Linux systems, clock-profiling of multithreaded applications will report inaccurate data for threads. The profile signal is not always delivered by the kernel to each thread at the specified interval; sometimes the signal is delivered to the wrong thread. If available, use hardware counter profiling using the cycle counter for more accurate per-thread results.

• On systems with multiple CPUs running at different clock frequencies, clock profiling will generate events based on the clock rate for one CPU, which can lead to over- or under-counting for events on other CPUs.

Thread Analyzer

This section describes known problems with the Thread Analyzer.

There might be a runtime failure of the Thread Analyzer, if ALL of the following is true:

• collect is run on a binary instrumented with discover for data race detection

• the run happens a machine with SPARC processor that supports hardware capability filters, such as the UltraSPARC T2

• the machine is running Solaris 10 Update 9 or an earlier update

To avoid the problem, before you run collect, set an environment variable LD_NOAUXFLTR=yes to skip loading the filter library. There might be some performance impact due to not using filters.

er_kernel Utility

This section describes known problems with the er_kernel utility:

• er_kernel sometimes can crash the machine on which it is run. The problem has only been seen on Oracle Solaris 10 running on UltraSPARC T1, T2, and T2+ chips and is due to a hypervisor bug.

• er_kernel profiles sometimes misattribute CPU state, and do not correctly report user data.

• Sometimes one or more CPUs will stop generating er_kernel events for 30 seconds or more.

• DTrace stack unwind for user processes sometimes omits one frame, typically when the leaf function is executing within its function prologue or epilogue.

• On systems with multiple CPUs running at different clock frequencies, er_kernel profiling generates events based on the clock rate for one CPU, which can lead to over-counting or under-counting for events on other CPUs.

IDE

This section describes known problems in the IDE.

• Versioning framework does not work in full remote mode.(195121)

  The versioning framework often works in terms of java.io.File, which makes it impossible to create a plugin capable of working with remote file objects.

  Workaround: Use versioning tools directly on the remote host through ssh.

• On some platforms, where GDB 7.2 is used, "Step Over" sometimes behaves as "Continue". (200196)

  Workaround: Try an earlier GDB version or change the Console Type in the Run section of the Project Properties from Internal Terminal to another option.

• Memory Access Error tool does not work for remote projects. (7109562)

  If you create a project on a remote host, and then instrument and run the project for memory analysis, you might receive the error message can't execute: discover: No such file or directory.

• Clicking the Debugger Console tab does not set focus to the debugger command prompt. (7102076)

  Workaround: Click a second time in the tab to set focus so that you can type a command at the prompt.

• Newly created full remote project from binary does not appear in the Projects tab. (7110094)

  When you are running a desktop distribution of the IDE and create a project from an existing binary on a remote host, the newly project does not appear in the Projects tab.

  Workaround: Choose File > Open Remote C/C++ Project and select the project to open.

• Can't create full remote project from binary on SPARC platform because binary is not recognized. (7109551)

  When you are running a desktop distribution of the IDE and create a project from an existing binary on a remote host that is a SPARC platform, and then choose File > Create Remote C/C++ Project, the binary is not recognized. If the filter in the file chooser is set to All Binary Files, the binary is not displayed; if the filter is set to All Files, you can select the binary, but will get the message “Binary file not found.”

dmake

This section discusses known dmake software problems and possible workarounds for those problems.

If there are any problems with using dmake in distributed mode, verify the following:

1. The $HOME environment variable is set to an accessible directory.

   % ls -la $HOME

2. The file $HOME/.dmakerc exists, is readable, and contains correct information.

   % cat $HOME/.dmakerc

3. All hosts mentioned in the $HOME/.dmakerc file are alive by using the /usr/sbin/ping command to check each host.

   % /usr/sbin/ping $HOST

   where $HOST is the name of the system, which is listed as the host in $HOME/.dmakerc file.

4. Verify that the path to the dmake binaries is correct by using the dmake, rxm, and rxs commands:

          % which dmake
          % which rxm
          % which rxs   

5. The remote login (rsh or ssh) on each host works without a password, and each remote login takes an acceptable time (less than 2 seconds).

   % time rsh $HOST uname -a

6. The file /etc/opt/SPROdmake/dmake.conf exists on each host and contains the correct information. If this file does not exist, dmake will distribute only one job on this system:

   % rsh $HOST cat /etc/opt/SPROdmake/dmake.conf

7. The path to the dmake binaries is correct for each host:

          % rsh $HOST `which dmake`
          % rsh $HOST `which rxm`
          % rsh $HOST `which rxs`    

8. The build area is available from each host (rwx):

          % cd $BUILD
          % rm $HOST.check.tmp
          % echo "Build area is available from host $HOST" > $HOST.check.tmp
          % rsh $HOST cat $BUILD/$HOST.check.tmp 

   where $BUILD is the full path to the build area.

9. That $HOME is available from each host:

          % cd $HOME
          % rm $HOST.check.tmp
          % echo "HOME is available from host $HOST" > $HOST.check.tmp
          % rsh $HOST cat $HOME/$HOST.check.tmp

dmake Limitations

You can use any machine as a build server as long as it meets the following requirements:

• From the dmake host (the machine you are using to start the build process) you must be able to use rsh or ssh without being prompted for the password to remotely execute commands on the build server.

• The bin directory in which the dmake software is installed must be accessible from the build server. By default, dmake assumes that the logical path to the dmake executables on the build server is the same as on the dmake host. You can override this assumption by specifying a path name as an attribute of the host entry in the runtime configuration file.

• The /etc/opt/SPROdmake/dmake.conf file exists on the host, is readable, and contains the correct information. If this file does not exist, dmake will distribute only one job on this system