JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
What's New In The Oracle Solaris Studio 12.2 Release
search filter icon
search icon

Document Information

Preface

1.  Introducing The Oracle Solaris Studio 12.2 Release

2.  Compilers

3.  Libraries

4.  Performance Analysis Tools

5.  Debugging Tools

6.  The Solaris Studio IDE

7.  Other Tools

8.  Known Problems, Limitations, and Workarounds in This Release

Compilers

Issues Common To The Compilers

Known problems related to --xprofile

C++

Correct Interpretation of Large Decimal Integer Constants

Ambiguity: Constructor Call or Pointer-to-Function

Template Syntax Error is No Longer Ignored

Linking Fails If You Combine -xipo or -xcrossfile With -instances=static

Cross-Language Linking Error

Name Mangling Linking Problems

Debugging Tools Erroneously Report Extra Leading Parameter for Member Functions

No Support For Referencing a Non-Global Namespace Object From a Template

#pragma align Inside Namespace Requires Mangled Names

Function Overload Resolution

Fortran

Array Intrinsic Functions Use Global Registers:

F95 Modules in Archive Libraries Not Included In Executable:

Tools

dbx

Known dbx issues and Workarounds

dbx Limitations and Incompatibilities

Performance Analyzer

dmake

dmake Limitations

Installation

Index

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:

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: