Core dump before entering main in Solaris 5.7 using SunWS 5.3 compiler

Question

Hi ..
I have a test program which links with one of our libraries. Both have been built using SunWS 5.3 compiler on Solaris 5.7 machine.
CC: Sun WorkShop 6 update 2 C++ 5.3 Patch 111685-19 2003/12/18
This test application cores even before it enters main(). The gdb stack trace is as follows :
#0 0xfeff9e94 in __sigprocmask ()
#1 0xfefef3f4 in _resetsig ()
#2 0xfefeebb0 in _sigon ()
#3 0xfeff19a0 in thrpkill ()
#4 0xff1b95a8 in abort ()
#5 0xff2741e8 in void __Cimpl::ex_terminate() ()
#6 0xff274c28 in exthrow_body ()
#7 0xff358478 in void std::locale::init() ()
#8 0x4363c in std::basic_streambuf<wchar_t,std::char_traits<wchar_t> >::basic_streambuf #Nvariant 1() ()
#9 0x416c8 in std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::basic_filebuf(int) ()
#10 0x3ae48 in std::__Wide_Init::__Wide_Init() ()
#11 0x3b044 in __SUNW_init_wiostreams ()
#12 0xff276364 in void __Cimpl::cplus_init() ()
#13 0xff277e18 in __cplus_fini_at_exit ()
#14 0xff3bcff0 in ?? ()
#15 0xff3bc764 in ?? ()
#16 0xff3c80c4 in ?? ()
#17 0xff3b2bf4 in ?? ()
The dbx stack trace is :
current thread: t@1
=>[1] __sigprocmask(0x0, 0xffbef098, 0x0, 0xffffffff, 0xffffffff, 0x0), at 0xfeff9e94
[2] _resetsig(0xff00cb24, 0x0, 0x0, 0x0, 0x8ac14, 0x8ac18), at 0xfefef3ec
[3] _sigon(0xff014458, 0xff014438, 0x8ac10, 0xffbef16c, 0x6, 0xff1ce178), at 0xfefeeba8
[4] thrpkill(0x0, 0x1, 0x6, 0xff00cb24, 0x8ab98, 0xff274818), at 0xfeff1998
[5] abort(0xff235f84, 0x0, 0xff3b2c28, 0x15888, 0x14620, 0xff2743b8), at 0xff1b95a0
[6] __Cimpl::ex_terminate(0x0, 0xff358538, 0xff28a940, 0xff3939a0, 0x3760c, 0x1), at 0xff2741e0
---- hidden frames, use 'where -h' to see them all ----
[8] std::locale::init(0x0, 0x0, 0xff00cb24, 0x0, 0x0, 0x2a8), at 0xff358470
[9] std::basic_streambuf<wchar_t,std::char_traits<wchar_t> >::basic_streambuf(0x86a60, 0x42b7c, 0x0, 0x0, 0x7c, 0x84218), at 0x43634
[10] std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::basic_filebuf(0x86a60, 0x0, 0x0, 0x4943c, 0x0, 0x0), at 0x416c0
[11] std::__Wide_Init::__Wide_Init(0x86ba8, 0x1, 0x0, 0x0, 0x0, 0x0), at 0x3ae40
[12] __SUNW_init_wiostreams(0xff394214, 0x3b030, 0xffffffff, 0xff394210, 0xff28a08c, 0xff28a820), at 0x3b03c
[13] __Cimpl::cplus_init(0x0, 0x0, 0x15bb8, 0xfeff68f8, 0xff28a748, 0xfffed858), at 0xff27635c
[14] 0xff277e10(0x0, 0xff3e6a8c, 0xff3e7004, 0xff3e7004, 0xff3e7004, 0xff3bcfe0), at 0xff277e0f
[15] call_init(0xff3e86c8, 0xff3e6aa8, 0xff3e6b7c, 0x200000, 0xfefd154c, 0xfefd1548), at 0xff3bcfe8
[16] setup(0xff3e8a70, 0xff3e6a10, 0x0, 0xff3e6aa8, 0x84890, 0x10074), at 0xff3bc75c
[17] _setup(0xff3b2774, 0x202, 0x300, 0xffffffff, 0xffffffff, 0xff3b0000), at 0xff3c80bc
[18] rtboot(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xff3b2bec
Interestingly, if I compile the same code on a Sun 5.6 machine with the same 5.3 compiler (CC: Sun WorkShop 6 update 2 C++ 5.3 2001/05/15), there is no core.
Looks like some global object is creating a problem since it is coring before entering main itself.
Does anybody have an idea of what is the problem ? Do I have to install any patch for this ?
Thanks in advance.
Ganesh

Answer 1

Hi Stephen ..
Thanks for your reply. I will definitely try what you suggested. But why does this work correctly when I build the library (.so) in Sun 5.6 and build the executable in 5.7 ??
Here are the ldd outputs for the library after being built on 5.6 and 5.7 respectively.
On 5.6 :
libc.so.1 => /usr/lib/libc.so.1
libposix4.so.1 => /usr/lib/libposix4.so.1
libthread.so.1 => /usr/lib/libthread.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libaio.so.1 => /usr/lib/libaio.so.1
/usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1
On 5.7 :
libc.so.1 => /usr/lib/libc.so.1
librt.so.1 => /usr/lib/librt.so.1
libthread.so.1 => /usr/lib/libthread.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libCrun.so.1 => /usr/lib/libCrun.so.1
libaio.so.1 => /usr/lib/libaio.so.1
libw.so.1 => /usr/lib/libw.so.1
/usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1
As you can see, there are slight differences, notable among them being libCrun ad libposix4. Could they be creating any problems ?
I saw a similar issue in this thread : http://forum.sun.com/thread.jspa?threadID=19986&tstart=150
It talks about patches which can solve this issue. Do you have an idea which patch can solve this issue ? (if it can :) )
Your reply is highly appreciated.
Thanks,
Ganesh