LibCstd.so.1 and libCrun.so.1

Hi
I an executable linked using CC version Forte Developer 7 C++ 5.4 2002/03/09. It works fine on the m/c where the executable is created.
On another m/c it comes out saying unable to find libCstd.so.1
(Both m/c are loaded with solaris 5.8)
a find /usr -name "libCstd*" doesn't give anything, meaning that library is not there.
Now my question is,
is that library libCstd.so.1 a standard C plus plus runtime library?
will it be there on all solaris 5.8 m/c even if CC is not installed?
I went through the man pages of CC and used the following options.
-library=no%Cstd, -library=iostream
Now when I do a ldd on my executable, the library libCstd.so.1 is not there and in its place I find libCrun.so.1
so is this libCrun.so.1 a standard runtime library?
I find this library under /usr/lib on both the m/cs
so can I assume that libCrun.so.1 will be there on all solaris 5.8 m/c even if CC is not installed?
is using the options -library=no%Cstd, -library=iostream a solution to this problem?
TIA
satya

Hi Paul,
On the system where I am creating the executable,
ls libC* geives
libC.so.3 libC.so.5 libCrun.so.1 libCstd.so.1
(This is a SunOS sun5 5.8 Generic_108528-13 sun4u sparc SUNW,Sun-Blade-1000 m/c)
On the system where I ran the executable and got the problem the ls libC* gives
libC.so.3 libC.so.5 libCrun.so.1
The env varialbe LD_LIBRARY_PATH is proper.
The compile line is as follows
/opt/SUNWspro/bin/cc -c -o /tmp/file.o -xO3 -I.
-I/usr/include -I-L/usr/openwin/include -L/usr/openwin/lib -I/usr/dt/include -I/usr/dt/lib -I/u1/satya/vdb/xmlparser/include -I/usr/java1.2/include -I/usr/java1.2/include/solaris -D__ogl -D__sun file.c
then the .o is arcieved to a static library.
(I have some 200 libraries for different modules)
and all those libs are linked using CC with the standard libs to get the executable.
The link line is like this
/opt/SUNWspro/bin/CC -o ../bin/exe -D_REENTRANT -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER -DSOLARIS -I. -I/usr/include -I-L/usr/openwin/include -L/usr/openwin/lib -I/usr/dt/include -I/usr/dt/lib -I/u1/satya/vdb/xmlparser/include -I/usr/java1.2/include -I/usr/java1.2/include/solaris ../sunlib/linkerr.o -xO3 -s -L/usr/openwin/lib -L/usr/dt/include -L-L/usr/openwin/include -L/usr/openwin/lib -L../sunlib -L/usr/dt/lib -L/u1/satya/vdb/vgui/lm/sunlib -L/usr/java1.2/jre/lib/sparc -L..//hdf/sunlib -lsocket -lnsl -lintl -llmgr -lGLU -lGL -lMrm -lXm -lXt -lXext -lXmu -lX11 -lm -lpthread and my application libs
The problem started after we moved to a new compiler
Earlier we were using CC: WorkShop Compilers 4.2 30 Oct 1996 C++ 4.2 and creating the executables on a
SunOS sun1 5.5.1 Generic_103640-31 sun4u sparc SUNW,Ultra-60 system. Now we have got a new m/c
with new compiler
M/c : SunOS sun5 5.8 Generic_108528-13 sun4u sparc SUNW,Sun-Blade-1000 and
CC: Forte Developer 7 C++ 5.4 2002/03/09
So are you saying that both libCstd.so.1 and libCrun.so.1 would be present on all solaris 5.8 m/cs?
(with or without CC installed).
One more info: an ldd on the executable created using older CC (C++ 4.2) gives libC.so.5 instead of libCstd.so.1
TIA
satya

Similar Messages

No symlinks to libC.so.5, libCrun.so.1 & libCstd.so.1 and where is libC.a?

The environment I use is as below;
Sun Solaris 5.8, Forte 6 update 2
The build command I use is ;
/opt/SUNWspro/WS6U2/bin/CC -o "release_suncc53/YMQF3410" \
-ptrrelease_suncc53/ -D__ODMG_93__ -D__SYS5__ -D_REENTRANT -L. \
-L/opt/SUNWspro/WS6U2/lib/v9 -L/usr/lib/64 -xildoff -xarch=generic64 release_suncc53/main.o \
-linfraXMLApi -linfraUtils \
-Bdynamic -lC -lCstd -lCrun -lgen -lsunmath_mt -lm -lw -lcx -lposix4 -lpthread -lc -lsocket -lnsl -lxerces-c ;
The above command by default (ie. when I dont use -Bdynamic) seems to libC.a libCstd.a & libCrun.a. When I
forced it to use the shared versions from /usr/lib/64, they were still not picked up. I notice that there are no
symlinks to these libraries in my installation.
[au02uap017qans2:san69:/usr/lib/64]ls -l libC*
-rwxr-xr-x 1 bin bin 324440 Dec 13 1999 libC.so.5
-rwxr-xr-x 1 root bin 79008 Jun 28 2006 libCrun.so.1
-rwxr-xr-x 1 root bin 2343808 Jun 28 2006 libCstd.so.1
I had create symlinks from some directory in the -L paths so that these were picked up.
Another point is that, when I try to use the archive libraries, I do not get the below symbols defined;
Undefined first referenced
symbol in file
void*operator new(unsigned long,void*) /export/home/bpo35/xerces64/lib/libxerces-c.so
void operator delete(void*,void*) /export/home/bpo35/xerces64/lib/libxerces-c.so
It is a nuisance to create the symlinks every time I try to build and I would like to know if there is
anything wrong with my installation. And where is my libC.a?

FD6 update 2 did not supply the symlinks for the C++ runtime libraries in the compiler area. The C++ Users Guide provides instructions on how to link the dynamic libraries via command-line options, or by adding symlinks yourself.
But this release is obsolete, and we very strongly recommend you abandon it in favor of Sun Studio 11 (if you run on Solaris 8).
Sun Studio 11 is free for all uses. It supports modern hardware, compiles faster, produces code that runs faster, has cool new development tools, and best of all, is fully supported. You can get Sun Studio 11 here:
[http://developers.sun.com/sunstudio/products/previous/11/index.jsp]

Can a gcc library linked to a CC app?

1) Is it possible to link a library 'L' to an App 'A'?
'L': C-interface, compiled with gcc, internal C++ structure, uses pthread, STL, USB
'A': CC compiled app
2) What are the settings? Does 'A' need a special gcc-library?
First tries gave runtime errors when opening the USB device
Thanks and best regards

Whether you can mix the code depends on conflicts betwen the g++ runtime library libstdc++.so.x and the Sun C++ runtime libraries libCstd.so.1 and libCrun.so.1, and conflicts in other run-time aspects of the generated code. The short answer is that real-world programs are unlikely to work.
Here is a more detailed answer:
Since g++ and Sun C++ use different name mangling schemes, C++ mangled function names (like functions from the C++ Standard Library) will not collide. (You cannot use any C++ types or functions in the library L interface, however.)
If library L and app A both use iostreams, you will have different buffered streams attached to the same standard file descriptors (0, 1, and 2 on Unix). You could get bizarre output or input failures. If you use iostreams on some other device, you can't share access in the two parts of the program for the same reason.
If the new and delete family of functions in libstdc++ just call malloc and free, you should not have conflicts with Sun C++ memory allocation. If libstdc++ does low-level heap management (by calling sbrk or something other than malloc/realloc/calloc/free), you will get heap corruption and program crashes.
I believe there are name conflicts in the exception-handling routines in libCrun.so.1 and libstdc++. If any of the code throws exceptions, you are likely to get a program crash.
There might be other problem areas as well. The list above is off the top of my head.
Some options:
1. Compile all the code using g++.
2. Compile all the code using Sun C++.
3. If library L was built with a compatible version of g++ and you are on a sparc system, you can use Sun's gcc for sparc systems to compile the application, or all of the code.

Help needed regards the usage of STL.....with CC

Hi All,
I am relatively new to SOLARIS. I am trying to figure out the options for using the STL components in the project.
The project needs to be compiled with both CC ang g++, should support both SOLARIS and LINUX systems. That's why i am going for STL components rather than using the RW-Components of Tools.h++.
I have the following doubts regards the usage of STL.
CC provides the -library option to link the libraries we require.
The following is what i understood from the documentation:
No ( -library ) option provides - default libraries included -lCstd -lCrun -lm -lw -lcx -lc+
-library=iostream+ - libraries included -liostream -lCstd -lCrun -lm -lw -lcx -lc+
-library=iostream,no%Crun+ - libraries included -liostream -lCstd -lm -lw -lcx -lc+
-library=stlport4+ - libraries included -lstlport4 -lCrun -lm -lw -lcx -lc+
-library=iostream,no%Cstd+ - Invalid combination, some header files missing [[ *iostream, sstream* ]]
When we try to make a new project, which of the following is recommended?
#! - Use libCstd suppplied along with solaris package.
When solaris makes a new release, is it always guaranteed that project is compatible with new libCstd ? (Is there a backward compatibility?)
The STL components which can be used in the project are limited. i.e we can use only those that come along with libCstd.....right?
Might not be compatible with other c++ compilers. ( Not compatible with g++ ) Right?
#2 - Use libCStd along with libiostream
Can we use STL (supported by libCstd ) + Classic-iostreams and still have the backward-compatibility?
Compatible with other C++ compilers....provided care has been taken of the CC STL Specializations. ( Compatible with g++ ) Right?
#3 - Use stlport4. Is it stable and backward-compatible ?
We can exploit usage of STL to the maximum.
Is it guranteed that the project (using -library=stlport4 ) will be backward compatible ?
Can the SunStudio (ORACLE) organization gurantee that stlport will take care of the changes in the CPP standards ?
i.e Is it guranteed that STLPORT and SUN-STUDIO packages will always be in sync?
Among the above three which is preferred method to go ensuring stability and backward-compatibility.
Thanks in advance.
Cheers,
Sreekar
Edited by: 855323 on 20-Oct-2011 04:04
Edited by: 855323 on 20-Oct-2011 04:04
Edited by: 855323 on 20-Oct-2011 04:06

In general, you don't need any options to use the C++ Standard Library (which includes what is sometimes loosely called the "STL"). Consider this toy program:
// file vec.cc
#include <vector>
#include <iostream>
int main()
    std::vector<int> vi(10);
    vi[1] = 1;
    std::cout << "vi[1]=" << vi[1] << '\n';
}You can compile and run the program as either
CC vec.cc && a.out
g++ vec.cc && a.outWith CC, by default you get the original libCstd. You use the -library option to select STLport or (on or selected versions of Solaris) Apache stdcxx instead. With g++, you just get the g++ library libstdc++, which should be suitable for all purposes.
For a discussion of which library to select with CC, see this thread:
Differnce between LibCstd and LibStlport
The optional libiostream is provided to provide support for programs written for the very old version of iostreams that was provided with the original AT&T Cfront compiler in the 1980's and early 1990's. There is usually no reason to use this obsolete library with code written after 1998.
The Solaris libCstd.so.1 (and libCrun.so.1) is always compatible with various releases of Studio, with one caveat: Each Studio release specifies the minimum patch level of Solaris libraries that is required to run programs created by the compiler. Any newer version of the library is guaranteed to be compatible. Thus, it is always safe to update the library, and an update might be required when using binaries created by a newer compiler.
A version of the STLport library ships with the compiler. C++ binaries created by an older compiler that link to libstlport.so.1 should still work when linked into a program created by a newer compiler. Use of the static libstlport.a is generally not safe when mixing binary code from different compiler releases.
Binaries created by Studio CC in default mode are not compatible with binaries created by g++. Even if you can get a program to link, which is doubtful, the program is not likely to run correctly.
Studio CC does provide a g++ compatibility mode as follows:
On supported versions of Linux with Studio 12.2 (C++ 5.11).
On Solaris/x86 and supported versions of Linux with Studio 12.3 (C++ 5.12).
In this mode, CC uses the g++ headers and the g++ runtime libraries.
Refer to the -compat=g option in the C++ Users Guide for details.
We plan to support the new C++ Standard, C++11, in a future compiler release. Because the ABI (binary interface) used by the current compilers is not adequate to support all the new features in C++11, we expect binaries built in C++11 mode to be incompatible with binaries created by earlier compilers. None of the existing C++ support libraries will be used in C++11 mode. A new library that provides full C++11 support will be used instead. We expect the new compiler to continue to provide the current C++03 mode as an option, being source and binary compatible with our earlier compilers.
Edited by: Steve_Clamage on Oct 20, 2011 10:00 AM
Edited by: Steve_Clamage on Oct 20, 2011 1:29 PM

Ldd does not show dependency on libC/ libCrun or libCstd

When I do an ldd on my executables (built using WS6U2), it does not show that it depends on libC/ libCrun or libCstd. But the executables use the iostream. More over, one of them fails with the below message;
ld.so.1: Rules: fatal: relocation error: file /opt/versant/cur_rel/lib/libcxxcls.so: symbol __1cDstdEcout_: referenced symbol not found
I initially thought the libCstd is not picked up as its path was not set in LD_LIBRARY_PATH. But setting it up right did not fix the issue. I finally had to preload libCstd using LD_PRELOAD to get the executable run.
My questions are;
1) Was the symbol __1cDstdEcout__ defined is some other library earlier and got moved to libCstd?
2) Why ldd does not list any of the C++ libraries (libC, libCrun or libCstd)?
3) What do libC, libCrun and libCstd provide? Does it provide any of the STL classes? I guess most of the STL comes from the headers itself (since most of them are templates)
Edited by: satheeshpaul on Dec 18, 2008 10:12 PM

satheeshpaul wrote:
2) Why ldd does not list any of the C++ libraries (libC, libCrun or libCstd)?Maybe because they are linked statically?
There's more reliable way to check:
$ elfdump -d a.out | grep NEED
       [0] NEEDED            0x215               libCstd.so.1
       [1] NEEDED            0x22d               libCrun.so.1
       [2] NEEDED            0x269               libm.so.2
       [3] NEEDED            0x243               libc.so.1If you don't see some library here, then a.out does not declare its dependency on that library. It might get loaded if some other library requests it, but in case of run-time support libraries, executable must declare dependency on those libraries (libCrun and such).
Now, it is very hard to determine whether or not your app was once linked with, say, libCrun statically. If you suspect that this is the case, you need to find a symbol unique to that library and try looking for it in a.out; if it is defined in a.out, it means that libCrun was linked statically; if you don't find it, well, it usually means close to nothing...
One more note: it is an error to mix statically compiled C++ run-time support libraries with their dynamic versions; in other words, if a.out was once linked with libCrun.a, for example, and libCrun.so gets loaded during program execution (it can happen for various reasons, one example is a.out is linked with some shared library that declares dependency on libCrun.so), things might get rough.
3) What do libC, libCrun and libCstd provide? Does it provide any of the STL classes? I guess most of the STL comes from the headers itself (since most of them are templates)You are right, most of STL comes from headers, but not all of STL. It's easy to find out what those libraries provide by looking at global symbols they export:
$ elfdump -s /usr/lib/libCstd.so.1 | c++filt | lessAlso, each library is described in User's Guide (highly recommended reading when you have particular question on Sun Studio C++ compiler):
http://docs.sun.com/app/docs/doc/806-7991
In short,
Crun - exception support, memory management, etc.
Cstd - STL
iostream - classic iostreams
C - Crun+iostream for compat=4 mode
satheeshpaul wrote:
I initially thought the libCstd is not picked up as its path was not set in LD_LIBRARY_PATH. But setting it up right did not fix the issue.Compiler records location of run-time support libraries when it build executable, so LD_LIBRARY_PATH is never needed unless you want to temporarily substitute one library for another for debugging purposes, for example.
satheeshpaul wrote:
I finally had to preload libCstd using LD_PRELOAD to get the executable run.You need to look at the way that executable was build; the problem must be in the build process somewhere. If you need help with that, please post command line used for final link step.

Ldd output and executables

I have my executables built on both Forte Developer 7 and Sun Studio 11.
When I run "ldd" on my executables on both the systems, I found the following differences :
Where as Forte developer 7 lists the following libraries :
libCstd.so.1,
libCrun.so.1 and
libw.so.1
But the above libraries were not listed for the executables on Sun Studio 11.
Where as Sun Studio 11 lists the following library :
libC.so.5
But the above library was not listed for the executables on Forte Developer 7.
And surprisingly, the code which was built on Studio 11 is running FINE on Forte Developer 7 !
Does it mean libC.so.5 compensates for libCstd.so.1, libCrun.so.1 and libw.so.1 ?
Should I worry that "My executables are running FINE on Forte Developer 7 which was compiled on Sun Studio 11" ?

The compatibility rule is that you can link your old binaries or 3rd-party binaries created by older compilers into a program built with a new compiler.
You cannot link system libraries from one compiler installation into a program built with a different compiler.
By default, the compiler links the shared (dynamic) version of libCstd and libCrun from /usr/lib. You can force the compiler to use the static versions of those libraries that come with the compiler, but we strongly recommend that you never link those libraries statically.
The shared libraries in /usr/lib are part of the Solaris installation, and are updated by Solaris patches for package SUNWlibC. The program picks up those libraries at run time from the system on which it is running.
Each compiler has a minimum required patch level for SUNWlibC (C++ Runtime Libraries). The required patch level is listed in the compiler documentation, and the patches are included in the compiler distribution. You can always use a later patch level than the minimum level.
You can get all current patches here:
http://developers.sun.com/prodtech/cc/downloads/patches/index.jsp

Sun Studio 12 C++ doesn't allocate variable in inline file

Hi Forum,
I've downloaded, installed and patched my SunStudio 12 on solaris (x86). My -V commands now say:
SunOS myhost 5.10 Generic_127112-02 i86pc i386 i86pc
CC: Sun C++ 5.9 SunOS_i386 Patch 124864-01 2007/07/25
cc: Sun C 5.9 SunOS_i386 Patch 124868-01 2007/07/12
f95: Sun Fortran 95 8.3 SunOS_i386 Patch 127002-01 2007/07/18I'm using GEANT4, a package for simulating particle interactions in high energy physics. It requires the CLHEP libary for mathematics, vectors (elements of a vector space, not stl) etc. You can download these here:
http://geant4.web.cern.ch/geant4/support/download.shtml (I'm using 9.0 p01)
http://proj-clhep.web.cern.ch/proj-clhep/DISTRIBUTION/distributions/clhep-2.0.3.1.tgz
Now, install the clhep and the Geant4, using
./configure; make; make check; make installfor CLHEP, then go to the G4 directory and change the Configure script from /bin/sh to bash (otherwise some test statements will not work). Then
./Configure -build (don't worry about the g4data directory, just keep the default, but take care to set debugging to yes. Also, say no to all graphical things, OpenGL, Motif, ...)
./Configure -install
./ConfigureNow, that you have the Geant4 libraries, source the new environment (env.sh/env.chs) to build the extended electromagnetic example:
cd examples/extended/electromagnetic/TestEm0
gmake
$G4WORKDIR/bin/$G4SYSTEM/TestEm0 TestEm0.inYou will get a segmentation fault.
Running dbx on the resulting core file yields
core file header read successfully
Reading ld.so.1
Reading libm.so.2
Reading libsunmath.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libCstd.so.1
Reading libCrun.so.1
Reading libc.so.1
Reading libm.so.1
Reading libdl.so.1
program terminated by signal SEGV (no mapping at the fault address)
Current function is G4PhysicsVector::GetValue
101 if( !(theEnergy != lastEnergy) ) {The corresponding source files are
source/global/management/include/G4PhysicsVector.hh
source/global/management/include/G4PhysicsVector.icc
source/global/management/src/G4PhysicsVector.cc
and reveal that lastEnergy is a G4double.
Unfortunately, I can't test this on the SPARC version of Studio 12.
While the developers now eagerly delve into this, let me downgrade to Studio 11 and check that id did work before.
Have a nice weekend,
Peter.

clamage45 wrote:
Apologies for not reading the original post carefully enough. I see that you got past the configuration, and the application > > > crashed at run time.
Hi Clamage, no worry.
If it worked with Studio 11, you have apparently run into a regression.
When you patched Studio 12, did you get the compiler common patch 126498-02? It fixes some regression in x86 code > > > generation.
In the meantime, I upgraded again from 11 to 12. I patched immediately and included the 126498-02:
-bash-3.00$ showrev -p | grep 126498
Patch: 127002-01 Obsoletes: Requires: 126498-01, 127003-01, 127144-01 Incompatibles: Packages: SPROf90, SPROl90, SPROl90x
Patch: 126498-02 Obsoletes: Requires: Incompatibles: Packages: SPROlang, SPROlangxSo I guess I'm on the right side of patching. Once again, the patches of the compilers themselves:
CC: Sun C++ 5.9 SunOS_i386 Patch 124864-01 2007/07/25
cc: Sun C 5.9 SunOS_i386 Patch 124868-01 2007/07/12
f95: Sun Fortran 95 8.3 SunOS_i386 Patch 127002-01 2007/07/18Alas, the problem persists and again, the code generated does not allocate (the suitable) memory for lastEnergy:
-bash-3.00$ dbx /export/home/niessen/geant4/bin/SUN-CC/TestEm0 core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc
Reading TestEm0
core file header read successfully
Reading ld.so.1
Reading libm.so.2
Reading libsunmath.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libCstd.so.1
Reading libCrun.so.1
Reading libc.so.1
Reading libm.so.1
Reading libdl.so.1
program terminated by signal SEGV (no mapping at the fault address)
Current function is G4PhysicsVector::GetValue
101 if( !(theEnergy != lastEnergy) ) {As a temporary remedy, I'm using the Studio11 compiled library with the Studio12 compiler. This seems to work so far.
Cheers and thanks for your attention,
Peter.

JMS-C debugging issue

Hi,
          I am using jmscapi for reading data from a JMS Queue.
          If I run the binary in dbx mode it stops in the JMSCreateContext() function call and displays this
          t@1 (l@1) signal SEGV (no mapping at the fault address) in (unknown) at 0xfa87fae0
          0xfa87fae0: bad opcode
          But if I run the same binary without dbx it works fine and it reads data from the JMS Queue successfully.
          Following is the stack trace with dbx mode:
          [SunOS]dbx ReadRequestQueue
          For information about new features see `help changes'
          To remove this message, put `dbxenv suppress_startup_message 7.1' in your .dbxrc
          Reading ReadRequestQueue
          Reading ld.so.1
          Reading libxerces-c.so.27
          Reading libjmsc.so
          Reading libjvm.so
          Reading librt.so.1
          Reading libCstd.so.1
          Reading libCrun.so.1
          Reading libm.so.1
          Reading libw.so.1
          Reading libc.so.1
          Reading libpthread.so.1
          Reading libnsl.so.1
          Reading libsocket.so.1
          Reading libdl.so.1
          Reading libthread.so.1
          Reading libaio.so.1
          Reading libmd5.so.1
          Reading libmp.so.2
          Reading libCstd_isa.so.1
          Reading libc_psr.so.1
          detected a multithreaded program
          (dbx) run
          Running: ReadRequestQueue
          (process id 27371)
          Reading libhpi.so
          Reading libverify.so
          Reading libjava.so
          Reading libzip.so
          t@1 (l@1) signal SEGV (no mapping at the fault address) in (unknown) at 0xfa87fae0
          0xfa87fae0: bad opcode
          Current function is main
          68 != JMS_NO_ERROR) {
          (dbx) where
          current thread: t@1
          [1] 0xfa87fae0(0xf25c6718, 0x1, 0xd, 0x34, 0xf65dcf70, 0xffbfcb50), at 0xfa87fadf
          [2] 0xfa805c64(0xf25c6568, 0xb7, 0xffbfccd8, 0xfa815238, 0xfa8150c4, 0xffbfcbf0), at 0xfa805c63
          [3] 0xfa805c64(0xf25c6568, 0xb6, 0xffbfcd60, 0xfa8151f0, 0xfa8150c4, 0xffbfcc70), at 0xfa805c63
          [4] 0xfa805b10(0xf25c6568, 0xb6, 0xffbfcde8, 0xfa815030, 0xfa8150c4, 0xffbfcd00), at 0xfa805b0f
          [5] 0xfa805b10(0xf25c6568, 0xb6, 0x8, 0xfa815030, 0xfa815284, 0xffbfcd80), at 0xfa805b0f
          [6] 0xfa805b10(0xf25c5540, 0xb7, 0x11, 0xfa815080, 0xfa815284, 0xffbfce18), at 0xfa805b0f
          [7] 0xfa805c64(0xf25c5540, 0xb7, 0xffbfcf74, 0xfa8151f0, 0xfa815284, 0xffbfce98), at 0xfa805c63
          [8] 0xfa805c64(0xf25c5540, 0xb7, 0xffbfcff8, 0xfa8151f0, 0xfa815284, 0xffbfcf18), at 0xfa805c63
          [9] 0xfa805c64(0xf25c5540, 0xb7, 0x3b, 0xfa815350, 0xf65c6180, 0xffbfcf98), at 0xfa805c63
          [10] 0xfa805c64(0x5a180, 0xb8, 0xffbfd118, 0xfa815240, 0xfa815284, 0xffbfd028), at 0xfa805c63
          [11] 0xfa805c64(0xf25c52a8, 0xb7, 0xffbfd198, 0xfa8153a0, 0xfa8150c4, 0xffbfd0b8), at 0xfa805c63
          [12] 0xfa805b54(0xf25c52a8, 0xb6, 0x23, 0xfa815238, 0xf65bb7a0, 0xffbfd138), at 0xfa805b53
          [13] 0xfa805b54(0xf25c4dd8, 0xb7, 0x8, 0xfa815080, 0xf65bb7a0, 0xffbfd1b8), at 0xfa805b53
          [14] 0xfa805c64(0xf25c4dd8, 0xb7, 0x34, 0xfa8151f0, 0xf65865c8, 0xffbfd240), at 0xfa805c63
          [15] 0xfa805c64(0xf25b2018, 0xb6, 0x8, 0xfa815240, 0xf65865c8, 0xffbfd2f0), at 0xfa805c63
          [16] 0xfa805c64(0xf25b2018, 0xb7, 0x78, 0xfa8154b0, 0xf6569f80, 0xffbfd380), at 0xfa805c63
          [17] 0xfa805c64(0x5a180, 0xb8, 0x8, 0xfa8151f0, 0xfa8153e4, 0xffbfd420), at 0xfa805c63
          [18] 0xfa805c64(0x5a180, 0xb8, 0x15, 0xfa815398, 0xf6569f80, 0xffbfd4c0), at 0xfa805c63
          [19] 0xfa805c64(0x5a180, 0xb8, 0x44, 0xfa815350, 0xf6562fd0, 0xffbfd558), at 0xfa805c63
          [20] 0xfa805c64(0x5a180, 0x0, 0x0, 0xfa8153a0, 0x361240, 0xffbfd5d8), at 0xfa805c63
          [21] 0xfa800118(0xffbfd6c4, 0xffbfd788, 0xa, 0xf6564b18, 0xfa80aae0, 0xffbfd794), at 0xfa800117
          [22] JavaCalls::call_helper(0xffbfd780, 0xffbfd77c, 0xffbfd790, 0x5a180, 0x5a180, 0x5c00), at 0xfe4d4b98
          [23] instanceKlass::call_class_initializer_impl(0xffbfd854, 0x5a180, 0xffbfd9ac, 0x5a180, 0x1, 0x0), at 0xfe4d4878
          [24] instanceKlass::call_class_initializer(0xf6564bc0, 0x5a180, 0x5a180, 0x5a180, 0xfe4dc7d4, 0xc), at 0xfe4d475c
          [25] instanceKlass::initialize_impl(0xffbfda10, 0x5a180, 0xffbfdc14, 0x10e5d8, 0x5a180, 0x1), at 0xfe4d42ac
          [26] instanceKlass::initialize(0xf6564bc0, 0x5a180, 0x5a180, 0xffbfd928, 0x2a, 0x13c), at 0xfe4d3d48
          [27] InterpreterRuntime::_new(0x5a180, 0xf6538b68, 0xb1, 0x2c4, 0xf6538b68, 0xffbfdab0), at 0xfe4dcd8c
          [28] 0xfa815854(0x5a180, 0x0, 0x0, 0xfa8104b0, 0x361240, 0xffbfdb48), at 0xfa815853
          [29] 0xfa800118(0xffbfdc34, 0xffbfdcf8, 0xa, 0xf653cab0, 0xfa80aae0, 0xffbfdd04), at 0xfa800117
          [30] JavaCalls::call_helper(0xffbfdcf0, 0xffbfdcec, 0xffbfdd00, 0x5a180, 0x5a180, 0x5c00), at 0xfe4d4b98
          [31] instanceKlass::call_class_initializer_impl(0xffbfddc4, 0x5a180, 0xffbfdf1c, 0x5a180, 0x59de0, 0x0), at 0xfe4d4878
          [32] instanceKlass::call_class_initializer(0xf653cc00, 0x5a180, 0x5a180, 0x5a180, 0x1, 0x0), at 0xfe4d475c
          [33] instanceKlass::initialize_impl(0xffbfdf80, 0x5a180, 0xffbfe604, 0x5a79c, 0x59870, 0x0), at 0xfe4d42ac
          [34] instanceKlass::initialize(0xf653cc00, 0x5a180, 0xffbfe00c, 0x0, 0x5a180, 0x0), at 0xfe4d3d48
          [35] find_class_from_class_loader(0x5a20c, 0xffbfe088, 0x1, 0xffbfe084, 0xffbfe078, 0x0), at 0xfe4e8b6c
          [36] JVM_FindClassFromClassLoader(0xfe828000, 0xffbfe100, 0x1, 0xffbfe25c, 0x0, 0x0), at 0xfe4f2780
          [37] Java_java_lang_Class_forName0(0x5a20c, 0xffbfe1e8, 0xffbfe264, 0x1, 0xffbfe25c, 0x0), at 0xfe87c1f8
          [38] 0xfa80bbc8(0xf26141e8, 0xb8, 0xffbfe2e4, 0xfa815030, 0xfa8153e4, 0xffbfe200), at 0xfa80bbc7
          [39] 0xfa805b10(0x5a180, 0xb8, 0x8, 0xfa815398, 0xf64089b8, 0xffbfe280), at 0xfa805b0f
          [40] 0xfa805b10(0xf2431840, 0xf6531a10, 0x8, 0xfa8153a0, 0xf6531a10, 0xffbfe310), at 0xfa805b0f
          [41] 0xfa805fd8(0x5a180, 0xb8, 0xffbfe494, 0xfa8154b0, 0xfa8150c4, 0xffbfe3b0), at 0xfa805fd7
          [42] 0xfa805b10(0xf26101a8, 0xb6, 0x8, 0xfa8153a0, 0xfa8150c4, 0xffbfe430), at 0xfa805b0f
          [43] 0xfa805b10(0xf24f9bf8, 0xb6, 0xffbfe590, 0xfa815030, 0xf6427128, 0xffbfe4b0), at 0xfa805b0f
          [44] 0xfa805c64(0xffbfe598, 0x0, 0x0, 0xfa815030, 0x361240, 0xffbfe530), at 0xfa805c63
          [45] 0xfa800118(0xffbfe624, 0xffbfe848, 0xa, 0xf6522130, 0xfa80aae0, 0xffbfe74c), at 0xfa800117
          [46] JavaCalls::call_helper(0xffbfe840, 0xffbfe6d8, 0xffbfe740, 0x5a180, 0x5a180, 0x5c00), at 0xfe4d4b98
          [47] jni_invoke_nonstatic(0x0, 0xfe83fdf8, 0x4000, 0x4380, 0x5a730, 0xffbfe824), at 0xfe4eb508
          [48] jni_NewObject(0x5a20c, 0x5abf4, 0xe5330, 0x5abf0, 0xff394e30, 0x20380d), at 0xfe5bd65c
          [49] JmsContextCreate(0xffbfeda4, 0x0, 0x0, 0x0, 0xffbfeda0, 0x0), at 0xff36e82c
          =>[50] main(argc = -228825368, argv = 0xf25c66e8), line 68 in "ReadRequestQueue.c"
          (dbx)
          Is there any way to skip over the JMSC function calls?
          Or can I get the source code of jmscapi so that I build it with -g option.
          Thank you in advance for your help.
          -Puja.

Hi Chirag,
In Background Job cases, I think BADI's can not be debugged directly by putting a break point. There is another way round using SM50. Please follow the below link. It may help you.
https://scn.sap.com/thread/1307038

Dbx check -access report wua when call vsnprintf

I don't undertand WHY I would get this "Write to unallocated (wua)" error? I tried purify, purify does NOT report this error.
#include <stdio.h>
#include <stdarg.h>
int write(char* buffer,const char* format, ...)
va_list vlist;
va_start(vlist,format);
printf("Buffer Address at %x\n", &buffer[0]);
int size = vsnprintf(&buffer[0], 2, format, vlist);
va_end(vlist);
return 0;
int main()
char* buffer = new char[2]; *// if I use char buffer[2] instead of new char[2], I wont get this error report!*
printf("Buffer Address at %x\n", buffer);
write(buffer,"%s\n", "xujian");
return 0;
CC -g -o test test.cpp
-bash-3.00$ dbx ./test
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.7' in your .dbxrc
Reading test
Reading ld.so.1
Reading libCstd.so.1
Reading libCrun.so.1
Reading libm.so.2
Reading libc.so.1
(dbx) check -access
access checking - ON
(dbx) run
Running: test
(process id 21660)
RTC: Enabling Error Checking...
RTC: Running program...
Reading disasm.so
Buffer Address at 80672a8
Buffer Address at 80672a8
Write to unallocated (wua):
Attempting to write 1 byte at address 0x80672aa
which is just past heap block of size 2 bytes at 0x80672a8
This block was allocated from:
*[1] operator new() at 0xecd06887*
*[2] operator new[]() at 0xecd05bdd*
*[3] main() at line 23 in "test.cpp"*
stopped in write at line 15 in file "test.cpp"
*15 int size = vsnprintf(&buffer[0], 2, format, vlist);*
(dbx)
Edited by: jianxu1 on Jan 19, 2010 1:49 AM

jianxu1 wrote:
Thanks, MaximKartashev~, Yes, I am on x86.
BTW, I noticed that bcheck(dbx check -access) is much much slower than purify~~ -:(Yes, Purify does not impact performance anywhere near as much as bcheck does.
Also, the behavior you're seeing seems consistent with trying to write the seven bytes of the string "xujian" into a two-byte buffer allocated from the heap. If you make that string more than 8 characters long, you should see Purify start to complain, too.
That's because malloc() (which the new operator uses), per the man page, "returns a pointer to a block of at least size bytes suitably aligned for any use." That phrase "suitably aligned for any use" effectively means that malloc()'d memory comes in 8-byte chunks. So even though you're asking for two bytes, you're getting a pointer to an eight-byte chunk. Ask for 9, and you'll get 16.
Your "char buffer[2];" variant doesn't get any errors from bcheck because bcheck doesn't do any run-time checking of automatic or stack variables. Purify should. I am somewhat surprised Purify doesn't give you an "array bounds write" (ABW) error on the "char buffer[2];" variant of your test case. Perhaps Purify has problems handling varargs and automatic variables. You may want to file a bug on Purify for that. FWIW, if you declare "char buffer[2]" and then try something like
char buffer[ 2 ];
strcpy( buffer, "ThisIsALongString" );Purify should give you an ABW for that.

Compiled binary crashes during initialization on Solaris 10/x86 platform

Hi, I have a problem to run application built with Solaris Sun Studio compiler. It dumps a core which contains:
$c_init+0x19a(1, 804761c, 8047624, 8047610, 80dabfd, 80da64c)
_start+0x78(1, 8047744, 0, 804774c, 8047756, 8047829)
>
When application is run under "dbx" utility the output looks:
Reading ld.so.1
Reading libTAO_CosNaming.so.1.4.0
Reading libTAO_Svc_Utils.so.1.4.0
Reading libTAO_IORTable.so.1.4.0
Reading libTAO_PortableServer.so.1.4.0
Reading libTAO.so.1.4.0
Reading libACE.so.5.4.0
Reading libxerces-c.so.28.0
Reading libicuuc.so.3
Reading libfbclient.so.2.1.1
Reading libdl.so.1
Reading libpthread.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libxnet.so.1
Reading librt.so.1
Reading libCstd.so.1
Reading libCrun.so.1
Reading libm.so.2
Reading libthread.so.1
Reading libc.so.1
Reading libTAO_Messaging.so.1.4.0
Reading libgen.so.1
Reading libTAO_ObjRefTemplate.so.1.4.0
Reading libTAO_Valuetype.so.1.4.0
Reading libTAO_IORInterceptor.so.1.4.0
Reading libicudata.so.3
Reading libcurses.so.1
Reading libaio.so.1
Reading libmd.so.1
(dbx) run
Running: app
(process id 13240)
t@1 (l@1) signal SEGV (no mapping at the fault address) in __cplus_fini_at_exit at 0x8393ba5
0x08393ba5: __cplus_fini_at_exit+0x01c9: addb %al,(%eax)
(dbx) where
current thread: t@1
=>[1] __cplus_fini_at_exit(0x8047664, 0x8047770, 0x804769c, 0x81ca778, 0x1, 0x80476a8), at 0x8393ba5
As you can see the application uses some 3rd party libraries, like: ACE (v5.4.0)/TAO (v1.4.0), xerces (v2.8), ICU (v1.2) and Firebird2 (v2.1.1) libraries. The libs were compiled using the same compiler. The problem seems to be within runtime linker - the core was dumped before the code started execution.
I have reproduced the issue with two different versions of compiler:
1. Older
/usr/bin/CC -V
CC: Sun C++ 5.9 SunOS_i386 Patch 124864-01 2007/07/25
uname -a
SunOS XXX 5.10 Generic_139556-08 i86pc i386 i86pc
2. Newer
/usr/bin/CC -V
CC: Sun C++ 5.9 SunOS_i386 Patch 124864-17 2009/10/27
uname -a
SunOS YYY 5.10 Generic_141415-04 i86pc i386 i86pc
Interesting observation, suggesting there is some problem with either linker or runtime linker:
I have a version of the application which runs properly but when I add just one line - include of one of ACE headers to the class which did not contain ACE I end up with the problem described above but if I add any number of includes of ACE headers to the class which already contained (directly or indirectly) ACE code the application still works.
The same source code is compiled on Solaris 9/SPARC platform and it works:
CC -V
CC: Sun C++ 5.5 Patch 113817-19 2006/10/13
uname -a
SunOS ZZZ 5.9 Generic_118558-35 sun4u sparc SUNW,Sun-Fire-V240
Is it any known issue? Thanks in advance for any input.

Hi
Thanks for the answer. I have analyzed my code and found out that, indeed, some static singleton objects were incorrectly implemented. It has been fixed and the application started when compiled under C++ 5.9, but it does not seem to solve the problem. The application was recompiled using the the newest Sun Studio 12.1 9 (C++ 5.10), and then failed to start again. As per your suggestion regarding the place in the code where the crash occurs, I have compared "__cplus_fini_at_exit" functions for both working and broken applications, compiled under C++ 5.9. Here are parts of code (actually, few last lines of the function) from:
- working
0x0827b811: __cplus_fini_at_exit+0x01b5:        call     __STATIC_CONSTRUCTOR   [ 0x81c9dec, .-0xb1a25 ]
0x0827b816: __cplus_fini_at_exit+0x01ba:        call     __STATIC_CONSTRUCTOR   [ 0x81cfb18, .-0xabcfe ]
0x0827b81b: __cplus_fini_at_exit+0x01bf:        call     __STATIC_CONSTRUCTOR   [ 0x81d1004, .-0xaa817 ]
0x0827b820: __cplus_fini_at_exit+0x01c4:        call     OPENSSL_cpuid_setup    [ 0x81e88a0, .-0x92f80 ]
0x0827b825: __cplus_fini_at_exit+0x01c9:        jmp      __cplus_fini_at_exit+0x1d4     [ 0x827b830, .+0xb ]
0x0827b827: __cplus_fini_at_exit+0x01cb:        movl     %esi,%esi
0x0827b829: __cplus_fini_at_exit+0x01cd:        leal     0x00000000(%edi),%edi
0x0827b830: __cplus_fini_at_exit+0x01d4:        nop
0x0827b831: __cplus_fini_at_exit+0x01d5:        popl     %ebx
0x0827b832: __cplus_fini_at_exit+0x01d6:        popl     %esi
0x0827b833: __cplus_fini_at_exit+0x01d7:        popl     %edi
0x0827b834: __cplus_fini_at_exit+0x01d8:        leave
0x0827b835: __cplus_fini_at_exit+0x01d9:        ret      $0x00000000- broken
0x0827b307: __cplus_fini_at_exit+0x01ab:        call     __STATIC_CONSTRUCTOR   [ 0x81c86e8, .-0xb2c1f ]
0x0827b30c: __cplus_fini_at_exit+0x01b0:        call     __STATIC_CONSTRUCTOR   [ 0x81c8eb4, .-0xb2458 ]
0x0827b311: __cplus_fini_at_exit+0x01b5:        call     __STATIC_CONSTRUCTOR   [ 0x81c9b2c, .-0xb17e5 ]
0x0827b316: __cplus_fini_at_exit+0x01ba:        addb     %al,(%eax) <=====
0x0827b318: __cplus_fini_at_exit+0x01bc:        addb     %al,(%eax)
0x0827b31a: __cplus_fini_at_exit+0x01be:        addb     %al,(%eax)
0x0827b31c: __cplus_fini_at_exit+0x01c0:        addb     %al,(%eax)
0x0827b31e: __cplus_fini_at_exit+0x01c2:        addb     %al,(%eax)
0x0827b320: __cplus_fini_at_exit+0x01c4:        call     OPENSSL_cpuid_setup    [ 0x81e83a0, .-0x92f80 ]
0x0827b325: __cplus_fini_at_exit+0x01c9:        jmp      __cplus_fini_at_exit+0x1d4     [ 0x827b330, .+0xb ]
0x0827b327: __cplus_fini_at_exit+0x01cb:        movl     %esi,%esi
0x0827b329: __cplus_fini_at_exit+0x01cd:        leal     0x00000000(%edi),%edi
0x0827b330: __cplus_fini_at_exit+0x01d4:        nop
0x0827b331: __cplus_fini_at_exit+0x01d5:        popl     %ebx
0x0827b332: __cplus_fini_at_exit+0x01d6:        popl     %esi
0x0827b333: __cplus_fini_at_exit+0x01d7:        popl     %edi
0x0827b334: __cplus_fini_at_exit+0x01d8:        leave
0x0827b335: __cplus_fini_at_exit+0x01d9:        ret      $0x00000000In the broken version, the crash occurs when executing addb     %al,(%eax) instruction at 0x0827b316 (marked above with an arrow). This is because %eax points to some read-only memory - the implementation of one of classes method in this case.
As you can see, in this address there are 5 2-byte long instructions addb     %al,(%eax). Their location in this place seems to make no sense from function logic point of view:
1. Why would we need to add %al register contents five times in a row, to the memory pointed by %eax, in this place?
2. The __cplus_fini_at_exit() function in the working application, that basically looks identical, does not have this sequence of instructions at all.
Looking at the memory dump in this place shows that these are physically 10 bytes of zeros ("e8 f4 ff 00 00 00 00 00 00 00 00 00 00 e8 7b d0") at 0x0827b316 (indeed, the instruction addb     %al,(%eax) is binary coded as 0x00 0x00). It seems, that for some reason, the block of 10 bytes with zero value was injected to the compiler generated code.
I would like to stress - this is not a result of program initialization as both listings presented above come from the applications loaded to "dbx" but not started so they only reflect how binaries look like. I have made one more test - I have edited broken binary and replaced these 10 bytes of zeros with ten "No Operation" instructions ("e8 f4 ff 90 90 90 90 90 90 90 90 90 90 e8 7b d0"). Here is output from "dbx", after the changes made:
0x0827b307: __cplus_fini_at_exit+0x01ab:        call     __STATIC_CONSTRUCTOR   [ 0x81c86e8, .-0xb2c1f ]
0x0827b30c: __cplus_fini_at_exit+0x01b0:        call     __STATIC_CONSTRUCTOR   [ 0x81c8eb4, .-0xb2458 ]
0x0827b311: __cplus_fini_at_exit+0x01b5:        call     __STATIC_CONSTRUCTOR   [ 0x81c9b2c, .-0xb17e5 ]
0x0827b316: __cplus_fini_at_exit+0x01ba:        nop
0x0827b317: __cplus_fini_at_exit+0x01bb:        nop
0x0827b318: __cplus_fini_at_exit+0x01bc:        nop
0x0827b319: __cplus_fini_at_exit+0x01bd:        nop
0x0827b31a: __cplus_fini_at_exit+0x01be:        nop
0x0827b31b: __cplus_fini_at_exit+0x01bf:        nop
0x0827b31c: __cplus_fini_at_exit+0x01c0:        nop
0x0827b31d: __cplus_fini_at_exit+0x01c1:        nop
0x0827b31e: __cplus_fini_at_exit+0x01c2:        nop
0x0827b31f: __cplus_fini_at_exit+0x01c3:        nop
0x0827b320: __cplus_fini_at_exit+0x01c4:        call     OPENSSL_cpuid_setup    [ 0x81e83a0, .-0x92f80 ]
0x0827b325: __cplus_fini_at_exit+0x01c9:        jmp      __cplus_fini_at_exit+0x1d4     [ 0x827b330, .+0xb ]
0x0827b327: __cplus_fini_at_exit+0x01cb:        movl     %esi,%esi
0x0827b329: __cplus_fini_at_exit+0x01cd:        leal     0x00000000(%edi),%edi
0x0827b330: __cplus_fini_at_exit+0x01d4:        nop
0x0827b331: __cplus_fini_at_exit+0x01d5:        popl     %ebx
0x0827b332: __cplus_fini_at_exit+0x01d6:        popl     %esi
0x0827b333: __cplus_fini_at_exit+0x01d7:        popl     %edi
0x0827b334: __cplus_fini_at_exit+0x01d8:        leave
0x0827b335: __cplus_fini_at_exit+0x01d9:        ret      $0x00000000This time the application has started. As everything occurs inside compiler-generated function it seems to me that this analysis strongly suggests that there is a problem with a compiler which puts 10 bytes of mess into __cplus_fini_at_exit.
The binaries used above were built using:
/usr/bin/CC -V
CC: Sun C++ 5.9 SunOS_i386 Patch 124864-01 2007/07/25
I have also checked Sun Studio 12.1 (C++ 5.10) compiler but the attempts to get working application failed (the same problem with zero bytes).
Have you ever encountered similar problem? Are you able to confirm/deny whether it is related to the compiler?
Thanks for further assistance

No mapping at the fault address error while accessing the string variable

Hi
we have a application which runs fine on AIX and HP but is throwing error on SOLARIS.
the application runs well (and use of string variables are also working fine ) till it hits Zone.cpp file
where the string variable is not getting initialized and throws no mapping at the fault address
the code snippet is as follows
#include <string>
#include <vector>
const string ZONE_ATTR_TYPE_ZN("ZN");
const string ZONE_ATTR_TYPE_FC("FC");
const string ZONE_ATTR_TYPE_ST("ST");
void Zone::AddAttributeValueAndCountryCode(const string &attributeValue,
                                                  Int attribSeq,
                                                  const string &countryCode,
                                                  ZoneSearchLocMap& zoneSearchLocMap)
     string key = "";
     if ((_attributeType == ZONE_ATTR_TYPE_FC) ||
          (_attributeType == ZONE_ATTR_TYPE_CT))
          key = _attributeType+DELIM+attributeValue;
we are running it on
CC: Sun C++ 5.9 SunOS_sparc Patch 124863-04 2008/04/16
compiled with these option
-g0 -xspace -KPIC -D_XPG5 -m32 -xarch=sparcvis -mt -DNCURSES -DEXC_HANDLING -DRW_NO_BOOL
and the created the execuatble with these option
-i -z rescan -g0 -xspace -mt -D_XPG5 -m32 -xarch=sparcvis -mt -DNCURSES -DEXC_HANDLING -DRW_NO_BOOL -lpthread -lsocket -lnsl -ldl -lposix4 -lCrun -lCstd -lc -lm -lnsl -lsocket
the dbx output
t@1 (l@1) program terminated by signal SEGV (no mapping at the fault address)
where -h
Current function is Zone::AddAttributeValueAndCountryCode
56 if ((_attributeType == ZONE_ATTR_TYPE_FC) ||
(dbx) where -h
current thread: t@1
=>[1] Zone::AddAttributeValueAndCountryCode(this = 0x194c088, attributeValue = CLASS, attribSeq = 1, countryCode = CLASS, zoneSearchLocMap = CLASS), line 56 in "Zone.cpp"
[2] ZoneLoader::Load(trans = CLASS, zoneList = CLASS, prZoneList = CLASS, zoneSearchLocMap = STRUCT, planningCompany = 0x1890f20), line 90 in "ZoneLoader.cpp"
[3] ZoneManager::ZoneManager(this = 0x1933e28, shipperId = 1000, consDBConnection = CLASS), line 24 in "ZoneManager.cpp"

I see you are compiling with -KPIC. Is the code going into a shared library?
Run "ldd" on all the C++ shared libraries you create, and on the main program. You should see a dependency on /usr/lib/libCrun.so.1 and /usr/lib/libCstd.so.1, and no dependency on any other libCrun or libCstd.
Do you have a particular reason for using -D_XPG5? Changing the Unix version presented by the system headers in /usr/include can sometimes create incompatibilities with the C++ headers and runtime libraries that are intended for the default Unix version.
Are all of the object files created with the same options, especially the -mt option?
If none of the above considerations raise any red flags, you might have run into a bug in the compiler or the C++ runtime libraries, or you might have a bug in your code that by accident does not show up in other environments.
There is no way to evaluate whether you have a compiler or runtime library bug without a test case that demonstrates the problem.
You might have heap or other data corruption in your program due to invalid pointer use, use of an uninitialized variable, reading or writing outside the bounds of an object, double deletion of an object, use of an object after it has been deleted. You might also have an MT programming error where a critical region is not properly guarded, or where a shared variable is not declared volatile.
By accident, data can be read or written incorrectly, or a data-race condition can exist, but without causing program failure. A program containing these errors can appear to run successfully on one platform and fail on another, or on the same platform under other conditions.
Running the program under dbx with Run-Time Checking enabled will show many of these errors.
The Thread Analyzer can find data race conditions.
If you think you have found a problem with the compiler or libraries, please file a bug report at
[http://bugs.sun.com]
with a test case that can be compiled and run to show the problem.

Ss12u1 on linux: relocation R_X86_64_32 against `a local symbol' can not be

hello all,
i've installed SS12u1 on a Sun x2270 under Centos 5.4.
We have to recompile a (veryhuge) scientific app that compiled fine on Solaris 10 amd64 with SS12u1, so the makefiles are identical between the two machines.
But, we faced the following error:
cd /mnt/PELICANS/PelicansTest/lib/octopus-CC/opt2/ ; \
CC -G -o /mnt/PELICANS/PelicansTest/lib/octopus-CC/opt2//../libpel2.so \
-fast -m64 \
-L/home/minjeaud/PELICANS/PelicansTest/lib/octopus-CC -R/home/minjeaud/PELICANS/PelicansTest/lib/octopus-CC \
-L/usr/local/UMFPACKv4.4/UMFPACK/Lib -R/usr/local/UMFPACKv4.4/UMFPACK/Lib \
-L/usr/local/UMFPACKv4.4/AMD/Lib -R/usr/local/UMFPACKv4.4/AMD/Lib \
-L/usr/include -R/usr/include    \
PDE_0D_Q0_1node.o   PDE_1D_P0_1node.o   PDE_1D_P1_2nodes.o   PDE_1D_P2_3nodes.o   PDE_2D_P0_1node.o   PDE_2D_P0_1node_RefinerA.o   ...........................
-lCstd -lCrun -lumfpack -lamd -lsunperf -lz -lm
/opt/sun/sunstudio12.1/prod/lib/amd64/ld: /opt/sun/sunstudio12.1/prod/lib/amd64/libmopt.a(f_atan2.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/opt/sun/sunstudio12.1/prod/lib/amd64/libmopt.a: could not read symbols: Bad valueI'm surprised that the error relates to a file included in Sunperf
The sunstudio is fully patched:
rpm -qf /opt/sun/sunstudio12.1/prod/lib/amd64/libmopt.a
sun-langx-12.1-3Is there a problem with this file?
if i suppress "-lm" on the command line, it seems to link correctly, but:
octopus:opt2> ldd ../libpel2.so
        libCstd.so.1 => /opt/sun/lib/rtlibs/amd64/libCstd.so.1 (0x00002b075804c000)
        libCrun.so.1 => /opt/sun/lib/rtlibs/amd64/libCrun.so.1 (0x00002b0758415000)
        libsunperf.so.3 => /opt/sun/sunstudio12.1/lib/amd64/libsunperf.so.3 (0x00002b075862c000)
        libc.so.6 => /lib64/libc.so.6 (0x00002b075b98c000)
        libm.so.6 => /lib64/libm.so.6 (0x00002b075bce3000)
        libfsu.so.1 => /opt/sun/sunstudio12.1/lib/amd64/libfsu.so.1 (0x00002b075bf67000)
        libfui.so.1 => /opt/sun/sunstudio12.1/lib/amd64/libfui.so.1 (0x00002b075c3d4000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003fc5e00000)
        libmtsk.so.1 => not found
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b075c50e000) i notice that there is a libm in /usr/lib, is it better than libm from sunstudio?
and why it doesn't find libmtsk? in solaris, libmtsk is in /usr/lib, i don't know if it exists in linux?
A find shows me that it exists here:
$ find /opt/sun/ -name libmtsk.so.1
/opt/sun/sunstudio12.1/rtlibs/libmtsk.so.1
/opt/sun/sunstudio12.1/rtlibs/amd64/libmtsk.so.1 Does it mean that i have to use LD_LIBRARY_PATH=/opt/sun/sunstudio12.1/rtlibs ?
Does a documentation exist for this kind of usage on linux?
Thanks in advance for help,
gerard

unfortunately, it doesn't work even with the -L -R flags:
CC -G -o /mnt/PELICANS/PelicansTest/lib/octopus-CC/opt2//../libpel2.so \
-fast -xnolibmopt -O4 -KPIC -m64 \
-L/home/minjeaud/PELICANS/PelicansTest/lib/octopus-CC -R/home/minjeaud/PELICANS/PelicansTest/lib/octopus-CC \
-L/usr/local/UMFPACKv4.4/UMFPACK/Lib -R/usr/local/UMFPACKv4.4/UMFPACK/Lib \
-L/usr/local/UMFPACKv4.4/AMD/Lib -R/usr/local/UMFPACKv4.4/AMD/Lib \
-L/usr/include -R/usr/include    \
-L/opt/sun/sunstudio12.1/rtlibs/amd64 -R/opt/sun/sunstudio12.1/rtlibs/amd64 \
PDE_0D_Q0_1node.o   PDE_1D_P0_1node.o   PDE_1D_P1_2nodes.o ...... \
-lCstd -lCrun -lc -library=sunperf -lumfpack -lamd -lz
ldd /mnt/PELICANS/PelicansTest/lib/octopus-CC/libpel2.so
        libCstd.so.1 => /opt/sun/sunstudio12.1/rtlibs/amd64/libCstd.so.1 (0x00002b560621a000)
        libCrun.so.1 => /opt/sun/sunstudio12.1/rtlibs/amd64/libCrun.so.1 (0x00002b56065e3000)
        libc.so.6 => /lib64/libc.so.6 (0x00002b56067fa000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00002b5606b52000)
        libsunperf.so.3 => /opt/sun/sunstudio12.1/lib/amd64/libsunperf.so.3 (0x00002b5606d66000)
        libfui.so.1 => /opt/sun/sunstudio12.1/lib/amd64/libfui.so.1 (0x00002b560a0c5000)
        libfsu.so.1 => /opt/sun/sunstudio12.1/lib/amd64/libfsu.so.1 (0x00002b560a1d6000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003fc5e00000)
        libm.so.6 => /lib64/libm.so.6 (0x00002b560a643000)
        libmtsk.so.1 => not found
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b560a8f0000)but if i use LD_LIBRARY_PATH:
( setenv LD_LIBRARY_PATH /opt/sun/sunstudio12.1/rtlibs/amd64 ; ldd /mnt/PELICANS/PelicansTest/lib/octopus-CC/opt2//../libpel2.so )
        libCstd.so.1 => /opt/sun/sunstudio12.1/rtlibs/amd64/libCstd.so.1 (0x00002ba0c37a7000)
        libCrun.so.1 => /opt/sun/sunstudio12.1/rtlibs/amd64/libCrun.so.1 (0x00002ba0c3b70000)
        libc.so.6 => /lib64/libc.so.6 (0x00002ba0c3d87000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00002ba0c40df000)
        libsunperf.so.3 => /opt/sun/sunstudio12.1/lib/amd64/libsunperf.so.3 (0x00002ba0c42f3000)
        libfui.so.1 => /opt/sun/sunstudio12.1/lib/amd64/libfui.so.1 (0x00002ba0c7652000)
        libfsu.so.1 => /opt/sun/sunstudio12.1/lib/amd64/libfsu.so.1 (0x00002ba0c7763000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003fc5e00000)
        libm.so.6 => /lib64/libm.so.6 (0x00002ba0c7bd0000)
        libmtsk.so.1 => /opt/sun/sunstudio12.1/rtlibs/amd64/libmtsk.so.1 (0x00002ba0c7e54000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002ba0c7fc5000)
        librt.so.1 => /lib64/librt.so.1 (0x00002ba0c81e0000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002ba0c83ea000)gerard

Application crashing even before entering main

my application is built using QT 4.7.2 with webkit. It results in segfault on running.
Debugger shows that it crashes before entering main. where command of dbx shows the following info:
(dbx) where
current thread: t@1
=>[1] _memcpy(0x6e2000, 0xfffffffffffffe08, 0x4a616e75, 0x4a614b68, 0x0, 0x0), at 0x7bd31268
[2] std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__clone(0x7bc83fec, 0x0, 0x4a616e75, 0x6dfcf8, 0x7bfff038, 0x6dfb00), at 0x7bf754f8
[3] std::basic_string<char,std::char_traits<char>,std::allocator<char> >::reserve(0x7bc83fec, 0xe, 0x0, 0x7, 0x6dfb00, 0x6dfb00), at 0x7bf6d7c0
[4] std::__copy<const char*,std::back_insert_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,int>(0xffbfe900, 0xffbfe8fc, 0x1, 0xffbfe8fc, 0x7bc837ab, 0x0), at 0x7bc3ef70
[5] std::_Init_timeinfo(0x7bc83ea8, 0xffbfe900, 0xffbfe8fc, 0x7bc83f50, 0x7bc83fec, 0x7bc837a4), at 0x7bc3cb78
[6] std::_Locale_impl::make_classic_locale(0x7bc83db0, 0x7bc83e98, 0x7bc83e9c, 0x7bc840a0, 0x7bc84094, 0x7c001300), at 0x7bc3fdf4
[7] std::locale::_S_initialize(0x7bc839ec, 0x1, 0x7bc7df6c, 0x7bc7df6c, 0x3d198, 0x0), at 0x7bc40df0
[8] __SLIP.INIT_A(0x0, 0x51c00, 0x4400, 0x7bc7df6c, 0x52414, 0x4630), at 0x7bc2bb78
[9] 0x7bc553d8(0x7fbf40fc, 0x7fbf5ad0, 0x2b3b4, 0x0, 0x7fbf4910, 0x821), at 0x7bc553d8
[10] call_init(0xc18081, 0x1, 0x7f8517d8, 0x7bc552e8, 0x7fbf4910, 0xffdfffff), at 0x7fbc52c0
[11] setup(0x200000, 0x2801, 0x602, 0x7fbf40fc, 0xc18001, 0x446), at 0x7fbc4828
[12] _setup(0x10034, 0xffffffff, 0x0, 0x7fbb0000, 0xffffffff, 0xffffffff), at 0x7fbd360c
[13] rtboot(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x7fbb84c0
(dbx)
what could be possible reasons?
How to detect where is the problem?
Any pointers?

I am using Solaris 10 and compiler forte 12.0
my application is using following libraries:
Reading ld.so.1
Reading libQtScript.so.4.7.2
Reading libclucene.so.0
Reading libX11.so.4
Reading libnsl.so.1
Reading libsocket.so.1
Reading libQtWebKit.so.4
Reading libQtXml.so.4.7.2
Reading libQtGui.so.4.7.2
Reading libQtNetwork.so.4.7.2
Reading libQtCore.so.4.7.2
Reading libpthread.so.1
Reading librt.so.1
Reading libCstd.so.1
Reading libCrun.so.1
Reading libm.so.2
Reading libthread.so.1
Reading libc.so.1
Reading libstlport.so.1
Reading libXrender.so.1
Reading libresolv.so.2
Reading libxnet.so.1
Reading libXext.so.0
Reading libstlport.so.1
Reading libfreetype.so.6
Reading libSM.so.6
Reading libICE.so.6
Reading libdl.so.1
Reading libaio.so.1
Reading libmd.so.1
Reading libm.so.1
Reading libCstd_isa.so.1
dbx output is :;
(dbx) stop in main
(2) stop in main
(dbx) stop at main.cpp:1
(3) stop at "main.cpp":110
(dbx) run
(process id 6870)
Reading libc_psr.so.1
t@1 (l@1) signal SEGV (no mapping at the fault address) in _memcpy at 0x7f830e20
0x7f830e20: _memcpy+0x0660: stda %f32, [%o0] 0xf0
First I thought that there is problem with memcpy function of libc_psr.so , so I stopped loading of this
library by setting environment variable LD_NOAUXFLTR to false
But there is no success

Libc.so.1 may crash my program

After successfully built TBB library (see http://forums.sun.com/thread.jspa?threadID=5434190&tstart=0), now I have a problem when I link TBB library with my program.
Here is the ldd's output of one of TBB libraries.
chenwj@niagara:~/work/svn/SPEC2006/tbb/trunk/build$ ldd SunOS_sparc_suncc_cc4.3
.3_kernel5.10_release/libtbb.so
        libdl.so.1 =>    /lib/sparcv9/libdl.so.1
        libpthread.so.1 =>       /lib/sparcv9/libpthread.so.1
        librt.so.1 =>    /lib/sparcv9/librt.so.1
        libstlport.so.1 =>       /opt/sunstudio12.1/lib/stlport4/v9/libstlport.so.1
        libaio.so.1 =>   /lib/64/libaio.so.1
        libmd.so.1 =>    /lib/64/libmd.so.1
        libc.so.1 =>     /lib/64/libc.so.1
        libCrun.so.1 => /usr/lib/64/libCrun.so.1
        libm.so.2 =>     /lib/64/libm.so.2
        /platform/SUNW,SPARC-Enterprise-T5120/lib/sparcv9/libmd_psr.so.1
        /platform/SUNW,SPARC-Enterprise-T5120/lib/sparcv9/libc_psr.so.1When I link TBB library with my program, segmentation fault just happen, even don't use anything related to TBB in my program. Here is an example.
chenwj@niagara:~/tmp$ cat tbb.cc
int main()
{}I compile it with libtbb.so.
chenwj@niagara:~/tmp$ CC -m64 -g -o tbb -R/home/chenwj/work/svn/SPEC2006/tbb/trunk/build/SunOS_sparc_suncc_cc4.3.3_kernel5.10_release/ -L/home/chenwj/work/svn/SPEC2006/tbb/trunk/build/SunOS_sparc_suncc_cc4.3.3_kernel5.10_release/ tbb.cc -ltbbAnd use dbx (Sun Studio debugging tool) to give me the stack trace. Here is the output.
chenwj@niagara:~/tmp$ dbx ./tbb
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.7' in your .dbxrc
Reading tbb
Reading ld.so.1
Reading libtbb.so
Reading libCstd.so.1
Reading libCrun.so.1
Reading libm.so.2
Reading libc.so.1
Reading libdl.so.1
Reading libpthread.so.1
Reading librt.so.1
Reading libstlport.so.1
Reading libaio.so.1
Reading libmd.so.1
(dbx) run
Running: tbb
(process id 17258)
t@1 (l@1) signal SEGV (no mapping at the fault address) in _private_memcpy at 0xffffffff7eb3a4d0
0xffffffff7eb3a4d0: _private_memcpy+0x0170: ld [%o1 + %g5], %o4
(dbx) where 1 -q -l
current thread: t@1
=>[1] libc.so.1:_private_memcpy()I wonder if there is a bug in libc.so?
Any suggestion will be appreciated.

Thanks!
I thought the "-library=stlport4" option is only need to be used through the library building process.
Let me see what are the differences between w/o "-library=stlport4" option.
With "-library=stlport4" option, the ldd's output is:
chenwj@niagara:~/tmp$ ldd tbb
        libtbb.so =>     /home/chenwj/work/svn/SPEC2006/tbb/trunk/build/SunOS_sparc_suncc_cc4.3.3_kernel5.10_release//libtbb.so
        libstlport.so.1 =>       /opt/sunstudio12.1/lib/stlport4/v9/libstlport.so.1
        librt.so.1 =>    /lib/sparcv9/librt.so.1
        libCrun.so.1 => /usr/lib/sparcv9/libCrun.so.1
        libm.so.2 =>     /lib/sparcv9/libm.so.2
        libc.so.1 =>     /lib/sparcv9/libc.so.1
        libdl.so.1 =>    /lib/sparcv9/libdl.so.1
        libpthread.so.1 =>       /lib/sparcv9/libpthread.so.1
        libaio.so.1 =>   /lib/64/libaio.so.1
        libmd.so.1 =>    /lib/64/libmd.so.1
        /platform/SUNW,SPARC-Enterprise-T5120/lib/sparcv9/libc_psr.so.1
        /platform/SUNW,SPARC-Enterprise-T5120/lib/sparcv9/libmd_psr.so.1Without "-library=stlport4" option, the ldd's output is:
chenwj@niagara:~/tmp$ ldd tbb
        libtbb.so =>     /home/chenwj/work/svn/SPEC2006/tbb/trunk/build/SunOS_sparc_suncc_cc4.3.3_kernel5.10_release//libtbb.so
        libCstd.so.1 => /usr/lib/sparcv9/libCstd.so.1
        libCrun.so.1 => /usr/lib/sparcv9/libCrun.so.1
        libm.so.2 =>     /lib/sparcv9/libm.so.2
        libc.so.1 =>     /lib/sparcv9/libc.so.1
        libdl.so.1 =>    /lib/sparcv9/libdl.so.1
        libpthread.so.1 =>       /lib/sparcv9/libpthread.so.1
        librt.so.1 =>    /lib/sparcv9/librt.so.1
        libstlport.so.1 =>       /opt/sunstudio12.1/lib/stlport4/v9/libstlport.so.1
        libaio.so.1 =>   /lib/64/libaio.so.1
        libmd.so.1 =>    /lib/64/libmd.so.1
        /platform/SUNW,SPARC-Enterprise-T5120/lib/sparcv9/libc_psr.so.1
        /platform/SUNW,SPARC-Enterprise-T5120/lib/sparcv9/libmd_psr.so.1So there are two imlementations of STL in this case, the default is the libCstd.so.1 and the other is ibstlport.so.1. If I do not specify "-library=stlport4" option, then there will be two imlementations of STL. So that my program crash.
Thanks again.

The er_print crashes while analyzing datarace

Dear all,
I have installed the latest Sun Studio12 and use its DRDT tools to detect the race condition.
After the execution of "collect -r on a.out", I can see that the experiement data has been successfully collected. But when I execute "er_print <tha.name>", er_print crashes.
The following is the related crash info:
# ls -lrht
total 12773670
drwxr-xr-x 2 rtp99 dba 512 Apr 10 13:56 MgmtFctAPI
drwxr-x--- 4 rtp99 dba 512 May 9 14:24 RtpEvtHdl01
-rw------- 1 rtp99 dba 900M Jun 8 14:09 core.pcs.19549.1181282948
-rw------- 1 zhf mobile 37M Jun 8 15:09 core.pcs.27127.1181286589
-rw------- 1 zhf mobile 547M Jun 8 15:18 core.pcs.27825.1181287097
-rw------- 1 rtp99 dba 911M Jun 8 16:34 core.pcs.4208.1181291656
drwxr-xr-x 33 rtp99 dba 1.0K Jun 8 16:45 pcs
-rw------- 1 rtp99 dba 371M Jun 8 16:49 core.pcs.6244.1181292550
-rw------- 1 rtp99 dba 239M Jun 8 16:57 core.pcs.7122.1181293055
-rw------- 1 rtp99 dba 235M Jun 8 17:11 core.pcs.8759.1181293881
-rw------- 1 zhf mobile 307M Jun 8 18:49 core.er_print.14083.1181299747
-rw------- 1 zhf mobile 307M Jun 8 18:52 core.er_print.14339.1181299906
-rw------- 1 zhf mobile 306M Jun 8 18:58 core.er_print.14882.1181300314
-rw------- 1 zhf mobile 237M Jun 8 19:00 core.er_print.14927.1181300421
-rw------- 1 zhf mobile 530M Jun 8 19:10 core.er_print.15816.1181300989
-rw------- 1 yyj mobile 237M Jun 11 09:40 core.er_print.24839.1181526011
-rw------- 1 yyj mobile 237M Jun 11 09:45 core.er_print.24927.1181526327
-rw------- 1 yyj mobile 306M Jun 11 10:33 core.er_print.26727.1181529189
-rw------- 1 yyj mobile 290M Jun 11 10:41 core.er_print.27057.1181529676
-rw------- 1 yyj mobile 237M Jun 11 11:41 core.er_print.2877.1181533293
# dbx /usr/bin/er_print core.er_print.27057.1181529676
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc
Reading er_print
core file header read successfully
Reading ld.so.1
Reading liber_dbe.so
Reading libCstd.so.1
Reading libCrun.so.1
Reading libc.so.1
Reading libdl.so.1
Reading libnsl.so.1
Reading libCstd_isa.so.1
Reading libc_psr.so.1
program terminated by signal SEGV (no mapping at the fault address)
0xfeed512c: freeunlocked+0x004c: ld [%i5 - 8], %o3
(dbx) threads
dbx: thread related commands not available
(dbx) where
=>[1] freeunlocked(0x61697473, 0x0, 0x931a8, 0xfef6fad4, 0xfef68298, 0x61697473), at 0xfeed512c
[2] free(0x61697473, 0xfeed50a8, 0x931e8, 0x1ff18, 0xfef68298, 0xfeed50a8), at 0xfeed50cc
[3] dbeGetRaceData(0x1, 0x6a42ea8, 0x6a30340, 0xff30e0ce, 0x1, 0x1), at 0xff276218
(dbx)
And I find that It alwasy crash in this race:
Race #2, Vaddr: 0xfcb24
Access 1: Read, __rwstd::__rb_tree<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::pair<const std::basic_string<char,std::char_traits<char>,std::allocator<char> >,pcsia::CIaBGFData*>,__rwstd::__select1st<std::pair<const std::basic_string<char,std::char_traits<char>,std::allocator<char> >,pcsia::CIaBGFData*>,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<const std::basic_string<char,std::char_traits<char>,std::allocator<char> >,pcsia::CIaBGFData*> > >::iterator::operator*()const + 0x00000098,
line 321 in "tree"
Access 2: Write, __rwstd::__rb_tree<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::pair<const std::basic_string<char,std::char_traits<char>,std::allocator<char> >,pcsia::CIaBGFData*>,__rwstd::__select1st<std::pair<const std::basic_string<char,std::char_traits<char>,std::allocator<char> >,pcsia::CIaBGFData*>,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<const std::basic_string<char,std::char_traits<char>,std::allocator<char> >,pcsia::CIaBGFData*> > >::iterator::operator=(const __rwstd::__rb_tree<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::pair<const std::basic_string<char,std::char_traits<char>,std::allocator<char> >,pcsia::CIaBGFData*>,__rwstd::__select1st<std::pair<const std::basic_string<char,std::char_traits<char>,std::allocator<char> >,pcsia::CIaBGFData*>,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<const std::basic_string<char,std::char_traits<char>,std::allocator<char> >,pcsia::CIaBGFData*> > >::iterator&) + 0x000000D4
Total Traces: 7
Segmentation fault (core dumped)
I asked a developer in SUN and he told me that "This could be a problem cause by long function name of C++ class member function"
Could developer of er_print have a look at this and give me some hints?
many thanks!
Cheers
Shen

Hi, Shen
This bug has been fixed in the first patch for Sun Studio 12. We will update the forum when the patch is released.
Thanks a lot!
-Xi

LibCstd.so.1 and libCrun.so.1

Similar Messages

Maybe you are looking for