Sun Studio C - Error while loading Multithreaded program on SUN. getting Lock problem
Hi ,
We are using datastage tx libraries in on of our appliation at API level.
The program is written in mix of c and c++ and libraries of Datastage tx version 7.5. However We recently installed version 8.1 on the same box and tried to compile the program with 8.1 version libraries of datastage tx. (No change is made except pointing to new libraries)
The program seems to be compiled gracefully. However while trying to run the program it fails with below error.
=========================================
current thread: t@1
=>[1] mutex_lock(0x8, 0x0, 0xfd2e0000, 0xfd30bba8, 0x1, 0x0), at 0xff241bac
[2] std::basic_ios<char,std::char_traits<char> >::init(0xfd3ae118, 0xfd3af648, 0x13738, 0x0, 0xfe46a538, 0x18), at 0xfd372840
[3] std::basic_istream<char,std::char_traits<char> >::basic_istream(0xfd3ae110, 0xfd3af648, 0xfa, 0x0, 0x8d0e4857, 0xb5c8), at 0xfd3725c4
[4] std::ios_base::Init::Init(0xfed93d28, 0x8d0e4857, 0xfbc502d0, 0x0, 0x8d0e3a58, 0xb5c8), at 0xfd363fc8
[5] __SLIP.INIT_J(0x0, 0xfd2c2078, 0xfd2e0000, 0xfd18a3d4, 0xfe46ac38, 0xfed80164), at 0xfed1fcc4
[6] __STATIC_CONSTRUCTOR(0x0, 0xfe46ab78, 0x15548, 0xff3ee7c4, 0x1391c, 0xfffd9c1c), at 0xfed5fc34
[7] 0xfed6d858(0x0, 0xfdc10600, 0x54, 0xfdc106dc, 0x19bb844, 0xf0000000), at 0xfed6d857
[8] call_init(0x400000, 0x80000, 0xff3ee7c4, 0xfd2f03ac, 0xffffffff, 0x0), at 0xff3c0208
[9] elf_bndr(0x1, 0x1f1, 0xfd327c5c, 0xfed02be4, 0x5, 0x0), at 0xff3ccd90
[10] _elf_rtbndr(0xfd366a68, 0x3a128, 0x0, 0x0, 0xfe46a538, 0x28), at 0xff3b3bb8
[11] 0xfd3a4d40(0xffbfeb58, 0xfd392444, 0xffbfeb57, 0x0, 0x0, 0x0), at 0xfd3a4d3f
[12] __rwstd::locale_imp::locale_imp(0xfd3aea38, 0xffbfeb58, 0x1, 0x0, 0xfe46a538, 0x40), at 0xfd366a68
[13] std::locale::init(0xc00, 0xc6c, 0x0, 0x0, 0x0, 0x0), at 0xfd36763c
[14] __SLIP.INIT_A(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfd363b74
[15] __STATIC_CONSTRUCTOR(0xfd363558, 0xfe46ab78, 0x15548, 0xff3ee7c4, 0x1391c, 0xfffd30fc), at 0xfd364e24
[16] _init(0x0, 0xfdc11c98, 0x44, 0xfdc11d3c, 0xfeefa478, 0xf0000000), at 0xfd379bd8
[17] call_init(0x400000, 0x80000, 0xff3ee7c4, 0xfd2f0230, 0xffffffff, 0x0), at 0xff3c0208
[18] elf_bndr(0x1, 0x47, 0xfe454014, 0xfd305298, 0x5, 0xffbfef64), at 0xff3ccd90
[19] _elf_rtbndr(0xfe456c5c, 0xfe46ac44, 0xfd2e0000, 0xfe455314, 0x5, 0xc10081), at 0xff3b3bb8
[20] 0xfe46a658(0xfe46ac44, 0x1, 0x31f28, 0x15234, 0xc10081, 0xfe46ac44), at 0xfe46a657
[21] __Cimpl::cplus_init(0x0, 0x0, 0x31ee0, 0xff3ee7c4, 0x1391c, 0xfffe25dc), at 0xfe456c5c
[22] _init(0x0, 0xfe0404c0, 0x1c, 0xfdc11dc8, 0xfd1e8748, 0xf0000000), at 0xfd2a0bfc
[23] call_init(0x400000, 0x80000, 0xff3ee7c4, 0xfd2f0218, 0xffffffff, 0x0), at 0xff3c0208
[24] elf_bndr(0x1, 0x0, 0x139b0, 0xfd2092c8, 0x5, 0xb5c8), at 0xff3ccd90
[25] _elf_rtbndr(0xfe458858, 0x8c9db360, 0xfbc50110, 0x0, 0xfe46ac38, 0xfe458e74), at 0xff3b3bb8
[26] 0x344ec(0xfe4587b0, 0x0, 0x15548, 0xff3ee7c4, 0xfffee2fc, 0xfffeddc0), at 0x344eb
[27] 0xfe458858(0x0, 0xfe0403f4, 0x18, 0xfdc11d74, 0xfe420390, 0xf0000000), at 0xfe458857
[28] call_init(0x400000, 0x80000, 0xff3ee7c4, 0xfd2f01e4, 0xffffffff, 0x0), at 0xff3c0208
[29] elf_bndr(0x1, 0x99, 0x140dc, 0xfe450fc4, 0x5, 0x0), at 0xff3ccd90
[30] _elf_rtbndr(0xfc40037c, 0x1, 0x31f28, 0xff3ee15c, 0xc10081, 0xff3ee7c4), at 0xff3b3bb8
[31] 0x344ec(0xfcd62cd0, 0x0, 0x31ee0, 0xff3ee7c4, 0xff3c42d4, 0x0), at 0x344eb
[32] _init(0x0, 0x0, 0xff300800, 0xe, 0xff3c0200, 0xff3ee7c4), at 0xfc40037c
[33] call_init(0x400000, 0x80000, 0xff3ee7c4, 0xfd2f0018, 0xffffffff, 0x0), at 0xff3c0208
[34] setup(0x0, 0x10094, 0x244e3, 0x2, 0x34c78, 0x6464e550), at 0xff3bf73c
[35] _setup(0x10034, 0x3f9, 0x3f9, 0xa, 0xa, 0xff3cdb8c), at 0xff3cdf80
[36] _rt_boot(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xff3b3b7c
==============================================
This seems to be primitive functions of the C/C++ where is is finding fault address to lock on. The program is a listener who spawn mutliper threads upon the request.
I would greatly help if anybody can direct on to find out the root cause of hte problem here.
Thanks.
[4357 byte] By [
addya] at [2007-11-26 23:32:17]

# 1
I forgot to add:
While trying to run I got core dump:
======================
(dbx) run
Running: tst_server
(process id 14249)
t@1 (l@1) signal SEGV (no mapping at the fault address) in mutex_lock at 0xff241bac
0xff241bac: mutex_lock+0x0014: ldub[%i0 + 5], %l1
(dbx) where
current thread: t@1
=>[1] mutex_lock(0x8, 0x0, 0xfd2e0000, 0xfd30bba8, 0x1, 0x0), at 0xff241bac
================================================
addya at 2007-7-10 14:44:46 >

# 2
The program crash seems to occur during the initialization of the C++ iostream library.
1. What C++ compiler version are you using? The command
CC -V
will report the version.
2. What is the patch level of the C++ runtime libraries on the version of Solaris you are using? Run these two commands:
uname -a
showrev -p | grep SUNWlibC
3. Is the final program link performed with CC? If not, be sure to use CC and not cc or ld to perform the link.
4. If the application is built from shared libraries, do all libraries have explicit dependencies on system libraries that they use? In particular, all shared libraries containing C++ code should have an explicit dependency on libCstd.so.1 and libCrun.so.1. Run the command
ldd somelib.so
to list the dependencies of library somelib.so. If dependencies are missing, that could explain the crash.
# 3
Thank you very much for replying.
To add more on this we have been working on the issue and found that we need solaris 10 version with Datastage tx 8.1 that will include sun studio 11 and compile package with it. We also had to upgrade to roguewave Software libary.
However doing all this upgrade, the program again seem to compile good. but we are now not able to execute the same. below is the result of running it from dbx.
NOTE: linking is done using CC only.
//*********************************/
(dbx) stop in main
More than one identifier 'main'.
Select one of the following:
0) Cancel
1) `dev_server`geserve.c`main
2) `libm4http.so`main
a) All
1
(2) stop in main
(dbx) run
Running: dev_server
(process id 7565)
^Cdbx: warning: Interrupt ignored but forwarded to child.
t@1 (l@1) signal INT (Interrupt) in __lwp_park at 0xfd2bfe3c
0xfd2bfe3c: __lwp_park+0x0010: ta8
(dbx) where
current thread: t@1
=>[1] __lwp_park(0x0, 0x0, 0x0, 0x0, 0xfd1ee000, 0x1), at 0xfd2bfe3c
[2] mutex_lock_queue(0x0, 0xfb9d04d0, 0xfeea696c, 0x0, 0x0, 0x1), at 0xfd2b8388
[3] mutex_lock_internal(0xfeea696c, 0x0, 0x1, 0x0, 0x10, 0xfd2ecbc0), at 0xfd2b8a94
[4] __rwstd::locale_imp::locale_imp(0xfd3aea38, 0xfeea6994, 0x1, 0x13798, 0xfe2ea780, 0x39928), at 0xfd366aac
[5] std::locale::init(0xc00, 0xc6c, 0x4c00, 0xfd3a406c, 0x0, 0x0), at 0xfd36763c
[6] std::basic_streambuf<char,std::char_traits<char> >::basic_streambuf(0xfd3af648, 0x2debc, 0x0, 0x0, 0x0, 0x0), at 0xfd379948
[7] std::basic_filebuf<char,std::char_traits<char> >::basic_filebuf(0xfd3af648, 0x0, 0xff000000, 0xff000000, 0x1084, 0x1), at 0xfd3761c4
[8] std::ios_base::Init::Init(0xfeea6960, 0x9cd19a80, 0xfeea5da0, 0xfffedb72, 0x1d7d0, 0x1dd24), at 0xfd363f74
[9] __SLIP.INIT_O(0x0, 0xfeea5da0, 0xfeea695c, 0x1d800, 0xbc0, 0x800), at 0xfee8809c
[10] __STATIC_CONSTRUCTOR(0x0, 0xfd2ecbc0, 0xa7bf4, 0xfe2d6dfc, 0xfcfa0580, 0xfcfa05c0), at 0xfee884b0
[11] 0xfee91ac8(0x0, 0x1, 0xfcfa2a00, 0xff3ec980, 0x30524, 0xff3ec268), at 0xfee91ac8
[12] call_init(0x1, 0xfee919d8, 0xff221cd8, 0xffdfffff, 0xff3ec980, 0xffffff7f), at 0xff3bfd4c
[13] elf_bndr(0xfee88cb0, 0x1021, 0xfd366a68, 0xff3ec0f8, 0xff3ee6a8, 0x0), at 0xff3cc32c
[14] elf_rtbndr(0xfd366a68, 0x398f8, 0x0, 0x13798, 0xfe2ea780, 0x398f8), at 0xff3b3804
[15] 0xfd3a4d40(0xffbfed60, 0xfd392444, 0xffbfed5f, 0xff3cc334, 0xfd2e8284, 0x0), at 0xfd3a4d40
[16] __rwstd::locale_imp::locale_imp(0xfd3aea38, 0xffbfed60, 0x1, 0x13798, 0xfe2ea780, 0x398b0), at 0xfd366a68
[17] std::locale::init(0xc00, 0xc6c, 0x4c00, 0xfcfa2a00, 0x0, 0x0), at 0xfd36763c
[18] __SLIP.INIT_A(0x0, 0xfd2ecbc0, 0xa7bf4, 0xfd2b6c08, 0xfcfa0500, 0xfcfa0540), at 0xfd363b74
[19] __STATIC_CONSTRUCTOR(0xfd363558, 0xfe2eaf74, 0x0, 0x1, 0x13984, 0xfd2e8284), at 0xfd364e24
[20] _init(0x0, 0x1, 0xfcfa2a00, 0xff3ec980, 0x30524, 0xff3ec268), at 0xfd379bd8
[21] call_init(0x1, 0xfd379b80, 0xfec31b60, 0xffdfffff, 0xff3ec980, 0xffffff7f), at 0xff3bfd4c
[22] elf_bndr(0xfd364e54, 0x1021, 0xfe2d6e40, 0xff3ec0f8, 0xff3ee6a8, 0x0), at 0xff3cc32c
[23] elf_rtbndr(0xfe2d6e40, 0xfe2eaea4, 0x0, 0xfcfa2a00, 0x0, 0x0), at 0xff3b3804
[24] 0xfe2ea8ac(0xfe2eaea4, 0xfd2ecbc0, 0xfe2ef0b8, 0x15360, 0x0, 0xfe2eaea4), at 0xfe2ea8ac
[25] __Cimpl::cplus_init(0x1, 0xfe2eaf74, 0xa7bf4, 0x0, 0x13984, 0xfcfa0100), at 0xfe2d6e40
[26] 0xfe2d8a8c(0x0, 0x1, 0xfcfa2a00, 0xff3ec980, 0x30524, 0xff3ec268), at 0xfe2d8a8c
[27] call_init(0x1, 0xfe2d89c4, 0xfea80018, 0xffdfffff, 0xff3ec980, 0xffffff7f), at 0xff3bfd4c
[28] elf_bndr(0xfe2d50dc, 0x1021, 0xff1623a8, 0xff3ec0f8, 0xff3ee6a8, 0x0), at 0xff3cc32c
[29] elf_rtbndr(0xff1623a8, 0xff3ec1c4, 0x202, 0xff3ec190, 0x0, 0x46), at 0xff3b3804
[30] 0x33cdc(0xff1726c0, 0xff3ee9f4, 0xff000000, 0xff000000, 0x30574, 0xff3ec268), at 0x33cdc
[31] 0xff1623a8(0x0, 0x1, 0xfcfa2a00, 0xff3ec980, 0x30524, 0xff3ec268), at 0xff1623a8
[32] call_init(0x1, 0xff162314, 0xff3014f0, 0xffdfffff, 0xff3ec980, 0xffffff7f), at 0xff3bfd4c
[33] setup(0xc10000, 0x0, 0xff3ec1c4, 0x0, 0xfcfb09cc, 0x10000000), at 0xff3bf278
[34] _setup(0x10034, 0xffffffff, 0xffbff7d4, 0xff3b0000, 0x0, 0xffffffff), at 0xff3cd488
[35] _rt_boot(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xff3b37c8
(dbx) where 100
current thread: t@1
=>[1] __lwp_park(0x0, 0x0, 0x0, 0x0, 0xfd1ee000, 0x1), at 0xfd2bfe3c
[2] mutex_lock_queue(0x0, 0xfb9d04d0, 0xfeea696c, 0x0, 0x0, 0x1), at 0xfd2b8388
[3] mutex_lock_internal(0xfeea696c, 0x0, 0x1, 0x0, 0x10, 0xfd2ecbc0), at 0xfd2b8a94
[4] __rwstd::locale_imp::locale_imp(0xfd3aea38, 0xfeea6994, 0x1, 0x13798, 0xfe2ea780, 0x39928), at 0xfd366aac
[5] std::locale::init(0xc00, 0xc6c, 0x4c00, 0xfd3a406c, 0x0, 0x0), at 0xfd36763c
[6] std::basic_streambuf<char,std::char_traits<char> >::basic_streambuf(0xfd3af648, 0x2debc, 0x0, 0x0, 0x0, 0x0), at 0xfd379948
[7] std::basic_filebuf<char,std::char_traits<char> >::basic_filebuf(0xfd3af648, 0x0, 0xff000000, 0xff000000, 0x1084, 0x1), at 0xfd3761c4
[8] std::ios_base::Init::Init(0xfeea6960, 0x9cd19a80, 0xfeea5da0, 0xfffedb72, 0x1d7d0, 0x1dd24), at 0xfd363f74
[9] __SLIP.INIT_O(0x0, 0xfeea5da0, 0xfeea695c, 0x1d800, 0xbc0, 0x800), at 0xfee8809c
[10] __STATIC_CONSTRUCTOR(0x0, 0xfd2ecbc0, 0xa7bf4, 0xfe2d6dfc, 0xfcfa0580, 0xfcfa05c0), at 0xfee884b0
[11] 0xfee91ac8(0x0, 0x1, 0xfcfa2a00, 0xff3ec980, 0x30524, 0xff3ec268), at 0xfee91ac8
[12] call_init(0x1, 0xfee919d8, 0xff221cd8, 0xffdfffff, 0xff3ec980, 0xffffff7f), at 0xff3bfd4c
[13] elf_bndr(0xfee88cb0, 0x1021, 0xfd366a68, 0xff3ec0f8, 0xff3ee6a8, 0x0), at 0xff3cc32c
[14] elf_rtbndr(0xfd366a68, 0x398f8, 0x0, 0x13798, 0xfe2ea780, 0x398f8), at 0xff3b3804
[15] 0xfd3a4d40(0xffbfed60, 0xfd392444, 0xffbfed5f, 0xff3cc334, 0xfd2e8284, 0x0), at 0xfd3a4d40
[16] __rwstd::locale_imp::locale_imp(0xfd3aea38, 0xffbfed60, 0x1, 0x13798, 0xfe2ea780, 0x398b0), at 0xfd366a68
[17] std::locale::init(0xc00, 0xc6c, 0x4c00, 0xfcfa2a00, 0x0, 0x0), at 0xfd36763c
[18] __SLIP.INIT_A(0x0, 0xfd2ecbc0, 0xa7bf4, 0xfd2b6c08, 0xfcfa0500, 0xfcfa0540), at 0xfd363b74
[19] __STATIC_CONSTRUCTOR(0xfd363558, 0xfe2eaf74, 0x0, 0x1, 0x13984, 0xfd2e8284), at 0xfd364e24
[20] _init(0x0, 0x1, 0xfcfa2a00, 0xff3ec980, 0x30524, 0xff3ec268), at 0xfd379bd8
[21] call_init(0x1, 0xfd379b80, 0xfec31b60, 0xffdfffff, 0xff3ec980, 0xffffff7f), at 0xff3bfd4c
[22] elf_bndr(0xfd364e54, 0x1021, 0xfe2d6e40, 0xff3ec0f8, 0xff3ee6a8, 0x0), at 0xff3cc32c
[23] elf_rtbndr(0xfe2d6e40, 0xfe2eaea4, 0x0, 0xfcfa2a00, 0x0, 0x0), at 0xff3b3804
[24] 0xfe2ea8ac(0xfe2eaea4, 0xfd2ecbc0, 0xfe2ef0b8, 0x15360, 0x0, 0xfe2eaea4), at 0xfe2ea8ac
[25] __Cimpl::cplus_init(0x1, 0xfe2eaf74, 0xa7bf4, 0x0, 0x13984, 0xfcfa0100), at 0xfe2d6e40
[26] 0xfe2d8a8c(0x0, 0x1, 0xfcfa2a00, 0xff3ec980, 0x30524, 0xff3ec268), at 0xfe2d8a8c
[27] call_init(0x1, 0xfe2d89c4, 0xfea80018, 0xffdfffff, 0xff3ec980, 0xffffff7f), at 0xff3bfd4c
[28] elf_bndr(0xfe2d50dc, 0x1021, 0xff1623a8, 0xff3ec0f8, 0xff3ee6a8, 0x0), at 0xff3cc32c
[29] elf_rtbndr(0xff1623a8, 0xff3ec1c4, 0x202, 0xff3ec190, 0x0, 0x46), at 0xff3b3804
[30] 0x33cdc(0xff1726c0, 0xff3ee9f4, 0xff000000, 0xff000000, 0x30574, 0xff3ec268), at 0x33cdc
[31] 0xff1623a8(0x0, 0x1, 0xfcfa2a00, 0xff3ec980, 0x30524, 0xff3ec268), at 0xff1623a8
[32] call_init(0x1, 0xff162314, 0xff3014f0, 0xffdfffff, 0xff3ec980, 0xffffff7f), at 0xff3bfd4c
[33] setup(0xc10000, 0x0, 0xff3ec1c4, 0x0, 0xfcfb09cc, 0x10000000), at 0xff3bf278
[34] _setup(0x10034, 0xffffffff, 0xffbff7d4, 0xff3b0000, 0x0, 0xffffffff), at 0xff3cd488
[35] _rt_boot(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xff3b37c8
(dbx) quit;
/***********************************/
It will be precious help if I can find any guide on this.
Thanks in Advance.
addya at 2007-7-10 14:44:46 >

# 4
What version of Solaris are you using? Run the command
uname -a
Are you building and running on the same system? If not what are the Solaris versions of the build system and the running system? (copy/paste the output of "uname -a" on each)
Are the C++ runtime libraries on the running system up to date? Run the command
showrev -p | grep SUNWlibC
and copy/paste the output.
What compiler version are you using? Run the command
CC -V
What do you mean by "We also had to upgrade to roguewave Software libary"? Did you just install recent patches for Sun C++ and the C++ runtime libraries? Or are you talking about software acquired directly from Rogue Wave? If you got software from Rogue Wave, exactly what is it, and how are you using it? That is, are you replacing Sun C++ runtime libraries with something from Rogue Wave?
# 5
Hi,
Thanks for your reqply, Highly appreciate it!!!
For your information,
1)Solaris Version:
$ uname -a
SunOS swsmiddle01 5.8 Generic_108528-27 sun4u sparc SUNW,Ultra-80
We are builiding and running application in same enviornment.
2)C++ Library :
$ showrev -p | grep SUNWlibC
Patch: 119963-04 Obsoletes: Requires: Incompatibles: Packages: SUNWlibC
3 )Compiler Version :
$ CC -V
CC: Sun C++ 5.8 2005/10/13
4) The rougeWave is a third party library being used by applicatoin to create a HTTP request. This does not replace the C++ libaries from SUN However.
Thanks,
Atul.
addya at 2007-7-10 14:44:46 >

# 6
You are using an unpatched compiler, and a very old version of C++ runtime libraries. You might be running into a bug that was long since fixed.
Get all the current patches for the compiler, the compiler back end, and the C++ runtime libraries for Solaris here:
http://developers.sun.com/sunstudio/downloads/patches/index.jsp
See if that fixes the problem.
# 7
Hi,
I am working with Atul on the same issue.
We have installed the patch and still seeing the error. Find below the details of our envoronment after patching:
uname -a
SunOS zdwsmiddle01 5.10 Generic_118822-18 sun4u sparc SUNW,Sun-Fire
showrev -p | grep SUNWlibC
Patch: 119963-04 Obsoletes: Requires: Incompatibles: Packages: SUNWlibC
Patch: 119963-08 Obsoletes: Requires: Incompatibles: Packages: SUNWlibC
CC -V
CC: Sun C++ 5.8 Patch 121017-10 2007/02/21
Currently we are getting the following error message when we try to execute through dbx.
(dbx) run
Running: dev_server
(process id 16372)
t@1 (l@1) signal SEGV (no mapping at the fault address) in mutex_lock_impl at 0xfd2b8dcc
0xfd2b8dcc: mutex_lock_impl+0x0010:ldub[%i0 + 5], %i4
(dbx) where
current thread: t@1
=>[1] mutex_lock_impl(0x8, 0x0, 0x0, 0x1000, 0x0, 0xfd2ecbc0), at 0xfd2b8dcc
[2] std::basic_ios<char,std::char_traits<char> >::init(0xfd3ae118, 0xfd3af648, 0x0, 0x137d4, 0xfe3ea810, 0x38fe0), at 0xfd372840
[3] std::basic_istream<char,std::char_traits<char> >::basic_istream(0xfd3ae110, 0xfd3af648, 0xfed206c4, 0xfffe342e, 0x79c6c, 0x1c800), at 0xfd3725c4
[4] std::ios_base::Init::Init(0xfed234b8, 0xfd2ecbc0, 0xfed234b4, 0xfed206c4, 0x2df0, 0x7a330), at 0xfd363fc8
[5] __SLIP.INIT_K(0x0, 0xfed206c4, 0xa7bf4, 0x79c00, 0x2df4, 0x2c00), at 0xfeca63b4
[6] 0xfeceac1c(0x0, 0x1, 0xfc3c2a00, 0xff3ec980, 0x30524, 0xff3ec268), at 0xfeceac1c
[7] call_init(0x1, 0xfeceab2c, 0xff221cd8, 0xffdfffff, 0xff3ec980, 0xffffff7f), at 0xff3bfd4c
[8] elf_bndr(0xfeca6d40, 0x1021, 0xfd366a68, 0xff3ec0f8, 0xff3ee6a8, 0x0), at 0xff3cc32c
[9] elf_rtbndr(0xfd366a68, 0x398d0, 0x0, 0x137d4, 0xfe3ea810, 0x398d0), at 0xff3b3804
[10] 0xfd3a4d40(0xffbfed48, 0xfd392444, 0xffbfed47, 0xff3cc334, 0xfd2e8284, 0x0), at 0xfd3a4d40
[11] __rwstd::locale_imp::locale_imp(0xfd3aea38, 0xffbfed48, 0x1, 0x137d4, 0xfe3ea810, 0x39888), at 0xfd366a68
[12] std::locale::init(0xc00, 0xc6c, 0x4c00, 0xfc3c2a00, 0x0, 0x0), at 0xfd36763c
[13] __SLIP.INIT_A(0x0, 0xfd2ecbc0, 0xa7bf4, 0xfd2b6c08, 0xfc3c0500, 0xfc3c0540), at 0xfd363b74
[14] __STATIC_CONSTRUCTOR(0xfd363558, 0xfe3eb004, 0x0, 0x1, 0x139c0, 0xfd2e8284), at 0xfd364e24
[15] _init(0x0, 0x1, 0xfc3c2a00, 0xff3ec980, 0x30524, 0xff3ec268), at 0xfd379bd8
[16] call_init(0x1, 0xfd379b80, 0xfeb81774, 0xffdfffff, 0xff3ec980, 0xffffff7f), at 0xff3bfd4c
[17] elf_bndr(0xfd364e54, 0x1021, 0xfe3d6e94, 0xff3ec0f8, 0xff3ee6a8, 0x0), at 0xff3cc32c
[18] elf_rtbndr(0xfe3d6e94, 0xfe3eaf34, 0x0, 0xfc3c2a00, 0x0, 0x0), at 0xff3b3804
[19] 0xfe3ea93c(0xfe3eaf34, 0xfd2ecbc0, 0xfe3ef178, 0x153bc, 0x0, 0xfe3eaf34), at 0xfe3ea93c
[20] __Cimpl::cplus_init(0x1, 0xfe3eb004, 0xa7bf4, 0x0, 0x139c0, 0xfc3c0100), at 0xfe3d6e94
[21] 0xfe3d8ae0(0x0, 0x1, 0xfc3c2a00, 0xff3ec980, 0x30524, 0xff3ec268), at 0xfe3d8ae0
[22] call_init(0x1, 0xfe3d8a18, 0xfeb81b9c, 0xffdfffff, 0xff3ec980, 0xffffff7f), at 0xff3bfd4c
[23] elf_bndr(0xfe3d5110, 0x1021, 0xff1623a8, 0xff3ec0f8, 0xff3ee6a8, 0x0), at 0xff3cc32c
[24] elf_rtbndr(0xff1623a8, 0xff3ec1c4, 0x202, 0xff3ec190, 0x0, 0x46), at 0xff3b3804
[25] 0x33cbc(0xff1726c0, 0xff3ee9f4, 0xff000000, 0xff000000, 0x30574, 0xff3ec268), at 0x33cbc
[26] 0xff1623a8(0x0, 0x1, 0xfc3c2a00, 0xff3ec980, 0x30524, 0xff3ec268), at 0xff1623a8
[27] call_init(0x1, 0xff162314, 0xff3014f0, 0xffdfffff, 0xff3ec980, 0xffffff7f), at 0xff3bfd4c
[28] setup(0xc10000, 0x0, 0xff3ec1c4, 0x0, 0xfcd70924, 0x10000000), at 0xff3bf278
[29] _setup(0x10034, 0xffffffff, 0xffbff7bc, 0xff3b0000, 0x0, 0xffffffff), at 0xff3cd488
[30] _rt_boot(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xff3b37c8
(dbx)
MIDLa at 2007-7-10 14:44:46 >

# 8
The stack trace looks like initialization of the standard iostream objects is getting some interference. I wonder if you have managed to get two copies of libCstd linked into the program. Please do the following:
1. Run ldd on the main program to get a list of all dependent libraries, and show that output.
2. Run ldd on each shared library in that list that is not a Solaris or Sun Studio system library, and show the output.
3. Show the complete CC command line that you use to build the main program.
Another possibility is memory corruption cause by something at initialization time. It might be instructive to run the program under dbx and turn on all Run-Time Checking:
%dbx myprog
(dbx) check -all
(dbx) run