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.2 dbx has the following limitations:

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

  • Fix and continue

    Performance data collection

    Breakpoints on the following events:

    • fault

      lastrites

      lwp_exit

      sysin

      sysout

      sync

      throw

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

  • Java debugging

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

• 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

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

  • 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. This happens less often when using the new threads library (NPTL).

    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.

• Run-time type information for C++ expressions is not available for programs compiled with the g++ compiler.

• 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 for compat=4. This is not a problem for compat=5.

  Workaround: Recompile your program with:

  CC —compat=4 —Qoption ccfe —abiopt=pmfun1

  This flag introduces an ABI change and should not be used in production builds.

• 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 -stackvar. 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 may 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.

Performance Analyzer

If your are using Linux with Oracle Message Passing Toolkit 8.2 or 8.2.1, you might need a workaround. The workaround is not needed for version 8.1 or 8.2.1c, or for any version if you are using an Oracle Solaris Studio compiler.

The Oracle Message Passing Toolkit version number is indicated by the installation path such as /opt/SUNWhpc/HPC8.2.1, or you can type mpirun —V to see output as follows where the version is shown in italics:

mpirun (Open MPI) 1.3.4r22104-ct8.2.1-b09d-r70

If your application is compiled with a GNU or Intel compiler, and you are using Oracle Message Passing Toolkit 8.2 or 8.2.1 for MPI, to obtain MPI state data you must use the -WI and --enable-new-dtags options with the Oracle Message Passing Toolkit link command. These options cause the executable to define RUNPATH in addition to RPATH, allowing the MPI State libraries to be enabled with the LD_LIBRARY_PATH environment variable.

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) 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 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