Updated 2004/12/06 |
Sun[tm] Studio 10: dbx Readme |
Contents
- Introduction
- About Sun Studio 10 dbx
- New and Changed Features
- Software Corrections
- Problems and Workarounds
- Limitations and Incompatibilities
- Documentation Errors
A. Introduction
This document describes the software corrections, known problems, limitations, and incompatibilities of this release.
Product Documentation
- Release Notes for Solaris Platforms: Available on the developer portal at http://developers.sun.com/tools/cc/documentation/ss10_docs/release_notes.html. Information in the release notes updates and extends information in all readme files.
- Release Notes for Linux Platforms: Available on the developer portal at http://developers.sun.com/tools/cc/documentation/ss10_docs/Linux_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/sunstudio10.
- IDE Documentation: Online help for all components of the Sun Studio IDE can be accessed from the Help menu in the IDE.
- Developer Resources Portal: For technical articles, code samples, documentation, and a knowledge base, see the developers portal at http://developers.sun.com/prodtech/cc.
B. About Sun Studio 10 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. This release of dbx is available on the following platforms:
- Solaris[tm] Operating System (Solaris OS), versions 8, 9, and 10
- Linux operating system:
- Sun[tm] Java Desktop System, Release 2
- SuSE Linux Enterprise Server 8
- RedHat Enterprise Linux 3
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 10 dbx.
- Support for the AMD64 architecture
The following features were added or changed in Sun Studio 9 dbx.
- Support for gcc and g++ compilers on Linux platforms
- Support for Fortran on Solaris OS on x86 based systems
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 10 release of dbx.
RTC Thinks Copying Padded Structs is a Problem (4460536)
With runtime checking enabled, dbx reported RUI (read from uninitialized memory) errors when a struct with gaps (holes or pads) between the data fields is copied. This problem has been fixed.
This section describes problems that were fixed in the Sun Studio 9 release of dbx.
- dbx can't print register contents or class members for optimized C++ code
- bcheck doesn't report all errors correctly
- dbx issues error messages (Error 0) while runtime checking sparcv9 code
- dbx kills processes it cannot control
- stop inclass/inobject take a long time
- 64-bit: Access checks on large contiguous heap block fail
- dbx fix and continue causes Pro/E to crash with SIGILL
dbx can't print register contents or class members for optimized C++ code (4964695)
Fixed in Sun Studio 8. dbx can now print registers (for example, $o7) and class members (for example, foo.x) for C++ code compiled with -g -xO4.
bcheck doesn't report all errors correctly (4460648)
Many out-of-bounds assignments to data structures on the heap that were missed are now being caught by runtime checking.
dbx issues error messages (Error 0) while runtime checking sparcv9 code (4975411)
Fixed in Sun Studio 8. Executing a 64-bit SPARC program under dbx with access checking enabled sometimes caused dbx to issue error messages such as:
dbx: read of 4 bytes at address 0x8 failed --- Error 0 dbx warning: internal handler (-396) made defunct --- could not enable event FRET"This has been fixed.
dbx kills processes it cannot control (5022145)
When dbx needed more memory and was unable to allocate it (the system was out of swap space, for instance), dbx would kill the process being debugged. This particular reported problem has been fixed. There may be other situations in which strange things happen when dbx cannot obtain additional memory. Try to avoid reaching system limits while debugging.
stop inclass/inobject take a long time (4952613)
Fixed in Sun Studio 8. This performance problem has been fixed.
64-bit: Access checks on large contiguous heap block fail (4958325)
dbx was using 32-bit values to store the size of heap blocks. Block sizes larger than that confused dbx. This has been fixed.
dbx fix and continue causes Pro/E to crash with SIGILL (4974233)
When dbx patched the addresses of replacement functions into the running executable, it sometimes got the addresses wrong. This has been fixed.
E. Problems and Workarounds
This section discusses known software problems and possible workarounds for those problems. For updates or patches, check the updated information at http://developers.sun.com/prodtech/cc/support_index.html.
- Data Collection Problems When dbx is Attached to a Process
- dbx does not check for an RUI coming from a copy constructor
- dbx might crash while debugging Java code
- dbx crashes on re-debugging of Java code
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 does not check for an RUI coming from a copy constructor
Runtime checking can erroneously report RUI (read from uninitialized memory) for inlined C++ copy constructors.
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.
F. Limitations and Incompatibilities
This section discusses limitations and incompatibilities with systems or other software. For last-minute information, see the release notes for Solaris platforms at http://developers.sun.com/tools/cc/documentation/ss10_docs/release_notes .html and the release notes for Linux platforms at http://developers.sun.com/tools/cc/documentation/ss10_docs/Linux_release_ notes.html
Sun Studio 10 dbx has the following limitations:
- The following features of dbx are not available on the AMD64 architecture:
- Memory access checking
- Support for debugging a program that uses libmtsk.so (OpenMP)
- The following features of dbx are not available on Linux platforms:
- Core file debugging
- Fix and continue
- Runtime checking
- Performance data collection
- Breakpoints on the following events:
- fault
- lastrites
- lwp_exit
- sysin
- sysout
- sync
- throw
- 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 Solaris OS x86 Platform Edition.
- 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/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/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.
Copyright © 2004 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.