Updated 2008/05/09 |
Sun[tm] Studio 12: dbx Readme |
Contents
- Introduction
- About Sun Studio 12 dbx
- New and Changed Features
- Software Corrections
- Problems and Workarounds
- Limitations and Incompatibilities
- Documentation Errata
A. Introduction
This document describes the software corrections, known problems, limitations, and incompatibilities of this release.
Product Documentation
- Release Notes: Available on the Sun Developer Network (SDN) Sun Studio portal at http://developers.sun.com/sunstudio/documentation/ss12/release_notes.html. Information in the release notes updates and extends information in all readme files.
- Sun Studio Documentation: Product man pages, HTML versions of readmes, and manuals can be accessed from /installation_directory/docs/index.html. The default installation directory on Solaris platforms is /opt/SUNWspro. The default installation directory on Linux platforms is /opt/sun/sunstudio12.
- IDE Documentation: Online help for all components of the Sun Studio IDE can be accessed from the Help menu and Help buttons in the IDE.
- Developer Resources Portal: For technical articles, code samples, documentation, and a knowledge base, see the SDN Sun Studio portal at http://developers.sun.com/sunstudio.
B. About Sun Studio 12 dbx
dbx is an interactive, source-level, command-line debugging tool. You can use it to run a program in a controlled manner and to inspect the state of a stopped program. dbx gives you complete control of the dynamic execution of a program, including the collection of performance data.
C. New and Changed Features
This section describes the new and changed features for dbx.
The following features were added or changed in Sun Studio 12 dbx.
- Support for access checking has been extended to x86 based systems and x64 based systems running the Solaris OS.
- adb mode is no longer supported.
- dbx can read separate debug files generated by [g]objcopy.
- Additional optimized code debugging support. For programs with dwarf location lists, local variable values can be printed, even in optimized code.
- New watch command added to complement the existing display command.
- Arrow keys are now bound to history and cursor motion in both emacs and vi ksh editing modes.
- Enhanced support for user-supplied pretty printing functions.
- New fortran_modules command
- New +l option for the print command prints only addresses of strings.
- New dbx environment variable debug_file_directory
- New dbx environment variable output_no_literal
- New dbx environment variable event_safety.
- The default value for dbx environment variable run_savetty has been changed to "off". This setting improves the performance of conditional or counted breakpoints. However, if you are debugging editors, shells or other applications that alter terminal settings, you need to set it manually to "on".
- New shell variable $exec32
- Data can be printed and examined and code can be disassembled and examined in the absence of a corefile or before a program is run. This information is extracted from the executable or shared libraries.
- dbx will now succeed in attaching to a process that is stopped due to SIGSTOP, SIGTSTOP, SIGTTIN or SIGTTOUT. Previously dbx would hang until the user explicitly resumed the process by issuing SIGCONT or foregrounding it.
A few features of dbx are not available for programs compiled with the gcc or g++ compilers, or for programs running on Linux platforms. For more information, see Limitations and Incompatibilities.
D. Software Corrections
This section describes problems that were fixed in the Sun Studio 12 release of dbx.
No new information is available at this time.
E. Problems and Workarounds
This section discusses known software problems and possible workarounds for those problems.
- Data Collection Problems When dbx is Attached to a Process
- dbx might crash while debugging Java code
- dbx crashes on re-debugging of Java code
- dbx cannot debug 32-bit multithreaded applications on Linux platforms
- dbx throws an exception when debugging application on different J2SE than it was built on
- False RUA error reported due to pre-RTC monitoring allocations
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. (4397578)
- 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 libcpclibrary 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.
dbx might crash while debugging Java code (4893079)
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.
dbx crashes on re-debugging of Java code (4801883)
Issuing two debug commands in a row on Java code might cause dbx to crash.
dbx cannot debug 32-bit multithreaded applications on Linux platforms
dbx cannot debug 32-bit multithreaded applications on SuSE Linux Enterprise Server 9.
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.
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 bu using the dxb supress command.
Check the support page on the SDN Sun Studio portal, http://developers.sun.com/sunstudio/support/ for the latest information.
F. Limitations and Incompatibilities
This section discusses limitations and incompatibilities with systems or other software. For last-minute information, see the release notes at http://developers.sun.com/sunstudio/documentation/ss12/release_notes.html
Sun Studio 12 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
- Runtime checking
- 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 -1Workarounds:
- 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 -1The 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.
- The memory access checking feature of runtime checking is not available on the Linux OS on x86 based systems or x64 based systems.
- 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=pmfun1This flag introduces an ABI change and should not be used in production builds.
- On V9 systems, stack traces that pass through code compiled with both the -g and -O options provide inaccurate results if the arguments are NOT integral types. Printing of float parameters in such functions may display the following error message:
RegSet::getd('o1'): cannot -- will return 0.0Workaround: Use -g only.
- On V9 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.
G. Documentation Errata
There is no new information at this time. Additional information might be made available at http://developers.sun.com/sunstudio/
Copyright © 2007 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.