SIGSEGV in __exit_handler ()

[cbuh]

Hello guys,

I've got an enormous error while shutting down my application on HP-UX B.11.31 U ia64 machine, while it works fine on HP-UX B.11.23 U ia64.

The gdb's message is:

Program received signal SIGSEGV, Segmentation fault
si_code: 1 - SEGV_MAPERR - Address not mapped to object.
0x9ffffffffb07dce0:0 in __exit_handler ()
at ../../../../../core/libs/libc/shared_em_64_perf/../core/gen/exit.c:374
374 ../../../../../core/libs/libc/shared_em_64_perf/../core/gen/exit.c: No such file or directory.
in ../../../../../core/libs/libc/shared_em_64_perf/../core/gen/exit.c


I've noticed that /lib/hpux64/libc.so.1 differs in these machines, but stood equal by name... ``strings'' says that:
11.31 has: $ B.11.31 Jun 5 2009 01:24:39 $ date stamp, while
11.23 has: $ PATCH_11.23/PHCO_36673 Aug 7 2007 02:44:44 $

Can anyone help me with the problem identification?

[Dennis Handly]

You'll need to disassemble the instructions to see where it is failing. It could be due to a bad atexit call. Or unloading a shlib that has the function.

(gdb) disas $pc-16*12 $pc+16*4
(gdb) info reg
(gdb) bt

>I've noticed that /lib/hpux64/libc.so.1 differs in these machines

Naturally, that's why one is 11.23 and the other is 11.31. ;-)

[cbuh]

I'm disassembling it already :) Will try to find the root of the problem.


>>I've noticed that /lib/hpux64/libc.so.1 differs in these machines

>Naturally, that's why one is 11.23 and the other is 11.31. ;-)

Why not differ in names? :-|

[Dennis Handly]

>I'm disassembling it already :)

(The implicit offer was to provide it and I would make suggestions.)

>Why not differ in names?

Since HP-UX is forward compatible, why keep an obsolete 11.23 libc on a 11.31 system?
Only 10.20 libs are kept with the previous name.

[Roland Piette]

Hello,

Seems to be a problem in your application. Did you control the options used at compile time witch can give problem for the linker !

Need more info to go ahead (compiler, language, ...).

Look also, if you have not side effect in the source code ... It will be hard to find out !

Good Luck,
Roland

[cbuh]

I've found the point!

This is the standard's weak point in scoped static class elements and dlclose():
http://www.sourceware.org/ml/libc-alpha/1999-q1/msg00273.html

Don't anybody knows some workaround for this?

[Dennis Handly]

>This is the Standard's weak point in scoped static class elements and dlclose():
http://www.sourceware.org/ml/libc-alpha/1999-q1/msg00273.html

dlclose is not part of the C++ Standard.

>Don't anybody know some workaround for this?

What compiler are you using? aC++ should handle this.
Do you have a stack trace?

[cbuh]

I use gcc 3.4.4 & 4.3.3. And I've found an Itanium C++ ABI (3.3.5.3 Runtime API -- section "C"), where local static destructors are registered using __cxa_atexit call.. and it should help me in theory, but...

But I ought to compile the code with gcc and link it with HPUX ld, and they don't understand each other in the implementation of the 3.3.5.3 Runtime API (it seems so, I'm not sure)... please see http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1370786 for the example.

[Dennis Handly]

>I ought to compile the code with gcc and link it with HPUX ld,

You must compile with g++. And NOT link directly with ld but use g++ to link.

>they don't understand each other in the implementation of the 3.3.5.3 Runtime API

The linker knows nothing about anything C++. This must be done in the C++ runtime lib.

And with aC++, we take a stick to dld to make sure everything works. :-)

[cbuh]

>>I ought to compile the code with gcc and link it with HPUX ld,

>You must compile with g++. And NOT link directly with ld but use g++ to link.

Yes-yes, I mean that, calling gcc as a common name ;).. compiled and linked via ``g++'' command, but it is configured to use --with-ld=/usr/ccs/bin/ld...

>>they don't understand each other in the implementation of the 3.3.5.3 Runtime API

>The linker knows nothing about anything C++. This must be done in the C++ runtime lib.

Yes, no C++ -- I agree, but due to the Itanuim C++ ABI section 3.3.5.3 "C" we have:
"When linking any DSO containing a call to __cxa_atexit, the linker should define a hidden symbol __dso_handle, with a value which is an address in one of the object's segments." This must be done in linktime ;)

>And with aC++, we take a stick to dld to make sure everything works. :-)

?