This section lists known limitations of the debugging tools and performance analysis tools.
dbx has the following limitations:
Using older copies of libC.so.5 or libC.so.4 might cause problems for dbx in the area of C++ exceptions. Warning messages about bad stabs and unhandled exceptions might 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 might not work properly with the –stackvar option. In such cases, try the –C compiler option, which enables array subscript checking without RTC.
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 on multithreaded applications.
Breakpoints on the following events:
fault
lastrites
lwp_exit
sysin
sysout
sync
Index DWARF (compiler option –xs=no)
The following problems might occur when debugging programs on Linux platforms:
To debug 32-bit programs, you must 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
Redirect command output to a file and then display the file contents.
(dbx) > bag where (dbx) cat bag
dbx does not support the following features for the GNU C and C++ compilers:
VL array (gcc 4.1 and before)
OpenMP
RTTI
Template definition
Default argument
using directive
friend
The following 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, be aware that dbx does not see macros defined using the –D compiler option.
The stabs format for debugging information is supported in Oracle Solaris Studio, but Oracle has announced that the format might eventually be discontinued in favor of DWARF format. Oracle is not required to implement stabs support for new features or for enhancements to existing features.
The following debugging features are not supported by the stabs format.
New C++11 features.
Parameters and local variables in optimized code.
Macros (when code is compiled with the –g3 option).
Subsets of debugging info (generally when compiled with –xdebuginfo={...}).
See dbx attach Profiling (collect -P) for information about data collection problems when dbx is attached to a process.
This section describes known problems with the Performance Analyzer tool and er_print utility.
The Library Visibility functionality for shared objects does not always work properly in conjunction with filtering.
Performance Analyzer and er_print cannot find shared objects embedded in jar files. In addition, under some circumstances Performance Analyzer and er_print cannot find Java class files or source files. To work around these issues, use addpath to point to the directories containing the files. See the Troubleshooting section of the Help in Performance Analyzer for more detailed information.
When you compare experiments you might see several issues:
Filters might not work properly.
Source and Disassembly views show inclusive and exclusive metrics instead of only inclusive metrics as expected.
Hyperlinks in Dual Source view do not always work.
If you set Comparison Style to Delta, the delta values are not displayed in Source and Disassembly views.
You might see the following issues related to CPUs with variable clock rate:
On a system with a variable clock rate, hardware counter profiling metrics for cycle-based counters are under-reported when the processor runs at less than maximum speed and the metrics are converted to times.
If you compare or aggregate multiple experiments that contain hardware counter data for cycle-based counters, and the experiments were recorded on machines with different clock rates, the timing metrics shown in data views are only correct for the first experiment. However, the metrics shown in the Overview are accurate.
On systems with multiple CPUs running at different clock frequencies, experiments will be processed based on the clock rate for one CPU, which can lead to over-counting or under-counting on other CPUs.
Profiling OpenMP applications that use many threads on SPARC T5, M5, and M6 systems might produce very large experiments that cannot be read. The workaround is to set the environment variable SP_COLLECTOR_NO_OMP before you run collect. Note that when you set this variable, you cannot see OpenMP constructs and metrics in the resulting experiment and the User, Expert, and Machine view modes all look the same.
Performance Analyzer discards experiments for which no callstacks were recorded during profiling.
Performance Analyzer cannot start if the hostname is not in /etc/hosts. The workaround is to ensure that the hostname is in /etc/hosts.
Remote login with a pass phrase is not yet supported.
This section describes known problems with the collect utility and data collection for the Performance Analyzer tool.
Profiling of mixed Java and C++ applications might not be complete when using JDK 1.7.0_40 through JDK 1.7.0_59 due to a bug in the JDK. The stack for calls from Java to C++ are not properly unwound.
Heap tracing on Linux does not trace calls to calloc.
Under some circumstances, using the ~system=1 attribute for hardware counter profiling might cause the application to fail or cause the Oracle Solaris operating system to crash or reset.
Collection of count data (collect -c) does not work for binaries that were compiled with –std=C++11.
This section describes known problems with the er_kernel utility.
er_kernel -t sometimes runs a few seconds longer than the requested interval.
er_kernel refuses to run on an Oracle Solaris system that is running under Oracle VM to avoid an Oracle VM bug that causes a reboot.
DTrace stack unwind sometimes omits a frame, typically when the leaf function is within its epilogue.
This section describes problems with profiling an application when using the dbx collector command.
There is a limitation in using the dbx collector on Java. You cannot specify a Java class file for the dbx target. Instead, you must specify the JVM as the target and specify the class file as a parameter to the dbx run command. For example:
> dbx /path-to-your-jdk/bin/java (dbx) collector enable (dbx) collector java on (dbx) run [JVM-options] [Java-class-file-to-execute]
On Linux, profiling of any Java applications with dbx or collect -P might fail.
When you perform hardware counter profiling in dbx, you must issue the command collector hwprofile on before issuing collector hwprofile counter or collector hwprofile addcounter commands that specify hi or lo. Otherwise an error will be reported.
For example:
> dbx target-program (dbx) collector hwprofile on (dbx) collector hwprofile counter hi
> dbx target-program (dbx) collector hwprofile on (dbx) collector hwprofile addcounter lo
This section describes problems with profiling a running application when using the dbx attach command:
If you attach dbx to a running process that was started without LD_PRELOAD to preload the collector library libcollector.so a number of errors can occur. You cannot collect any tracing data: synchronization wait tracing, heap tracing, I/O 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 target 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 in Oracle Solaris or the SIGIO signal in Linux, some or all profiling data might be lost.
If the target program uses libcpc.so hardware-counter experiments might fail because both the collector and the program are using the library.
If the target program calls setitimer (2), clock profiling experiments can be corrupted because both the collector and the program are using the timer.
Attaching to a target that is in the middle of a call into the malloc library might cause the target to fail. Requesting hardware counters when attaching greatly increases the probability of such failures.
Attaching to a Java program fails unless the collector java on command or collect -j on -P pid is used.
On Linux, attaching to a Java program with dbx or collect -P might fail.
On Linux, attaching to a target that is in the middle of a blocking or non-blocking call might cause the target to fail.
On Linux, attaching to a multithreaded target will not properly record data for threads that are already created at the time of the attach. No warning about missing data is provided. Note that this includes any Java targets because the JVM is multithreaded.
This section describes known limitations in the IDE.
To create a project from binary on a remote host, the remote host must have Oracle Solaris Studio 12.4 or Oracle Solaris Studio 12.3 available. This feature is not supported on earlier releases.
This section describes known limitations to the Code Analyzer tools.
The discover and uncover tools do not work with an x86_64 binary compiled with –xmodel=medium when the program size (text + data) is large enough to extend beyond the maximum range of –xmodel=small (232 - 224 - 1).
The discover tool doesn't work on an ancillary file, which is a file containing debug information created with the linker option –-z ancillary in Oracle Solaris 11.2.
The discover tool does not report UMRs and PIRs with compiled with C++11.
To use any of the Code Analysis tools on Oracle Linux, the original binary must be compiled and linked with the –xannotate=[yes] option.