Compiled binary crashes during initialization on Solaris 10/x86 platform

Question

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.

Answer 1

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