Dynamic loading of DCE-RPC client library problem

[Grischa]

Hello all,
I have problems performing dynamic loading of a DCE-RPC client-library on hp-ux 11.11 and 11.23, using dlopen/dlcolse functions. If the library is unloaded by dlclose, an error creating a core-dump occurs at program exit.
Problem seems that rpc-client-library must be linked to thread library libdcekt.so, and this seems to be not 100% compatibel to other program modules which are not linked to libdcekt.so, or which are linked just to libpthread.so.
If the rpc-client-library is not unloaded, or if the loading modules are also linked to libdcekt.so, no error occurs.
Please see attached file for more information got from core file and used compile/linker flags.
Thank you.

[Grischa]

core file information and used compile/linker flags:

hp-ux 11.23 error message:

plabel copyin failed. 0x200000007ef6e160
Pid 7934 was killed due to failure in writing the signal context - possible stack overflow.

hp-ux 11.23 core information:

Program terminated with signal 4, Illegal instruction.
ILL_ILLOPC - Illegal Op-Code
#0 0x60000000c0877040:0 in __cxa_finalize+0x280 ()
from /usr/lib/hpux32/libCsup.so.1
(gdb) bt
#0 0x60000000c0877040:0 in __cxa_finalize+0x280 ()
from /usr/lib/hpux32/libCsup.so.1
#1 0x60000000c0876d70:0 in __cxxTerm_body()+0x30 ()
from /usr/lib/hpux32/libCsup.so.1
#2 0x60000000c0876c40:0 in __cxxTerm+0x20 () from /usr/lib/hpux32/libCsup.so.1
#3 0x60000000c01ef840:0 in __exit_handler+0xa0 ()
from /usr/lib/hpux32/libc.so.1


hp-ux 11.23 compile and link flags of rpc-client library:

aCC ... -D_REENTRANT -mt -D_HPUX_SOURCE +z -b -ldcekt


hp-ux 11.23 compile and link flags of loading executable:

aCC ... -mt -D_REENTRANT -D_HPUX_SOURCE


hp-ux 11.11 error message:

Pid 8040 was killed due to failure in writing the signal context.
./rundyn.sh: line 1: 8040 Illegal instruction (core dumped)


hp-ux 11.11 core information:

Program terminated with signal 4, Illegal instruction.
ILL_UNKNOWN - Unknown Error
(no debugging symbols found)...(no debugging symbols found)...#0 0xc0137b30 in $$dyncall_external+0 () from /usr/lib/libc.2
(gdb) bt
#0 0xc0137b30 in $$dyncall_external+0 () from /usr/lib/libc.2
#1 0xc01849ec in exit+0x74 () from /usr/lib/libc.2


hp-ux 11.11 compile and link flags of rpc-client library:

gcc ... -D_POSIX_D10_THREADS -D_POSIX_C_SOURCE=199506L -D_HPUX_SOURCE -D_REENTRANT -D_THREAD_SAFE -fPIC -ldcekt -lpthread


hp-ux 11.11 compile and link flags of loading executable:

gcc ... -D_POSIX_D10_THREADS -D_POSIX_C_SOURCE=199506L -D_HPUX_SOURCE -D_REENTRANT -D_THREAD_SAFE -lpthread -lstdc++

[Grischa]

Attached you will find some test app for hpux 11.23.

[Dennis Handly]

>Problem seems that rpc-client-library must be linked to thread library libdcekt.so, and this seems to be not 100% compatible to other program modules which are not linked to libdcekt.so

(Note a corefile is useless without copies of ALL shared libs. You should look at gdb's packcore command to capture this.)

When your application aborts, info shared shows that the address in question is in your unloaded libdcekt.so, called from the aC++ runtime to handle dtors and atexit.

Yes, libdcekt.so calls atexit. This calls the libCsup version. I thought this would be an issue but it turns out it isn't. libCsup has this same issue but it tells dld to never unload itself.

So you either need to get libdcekt.so "fixed", or you must link your application and not your plugin with libdcekt.so so it is never unloaded.
aCC ... -o main ... -ldcekt

Breakpoint 1, 0x2000000076dcadc0:0 in __cxa_atexit+0x30 libCsup.so.1
(gdb) bt
#0 0x2000000076dcadc0:0 in __cxa_atexit+0x30 libCsup.so.1
#1 0x2000000076dcad30:0 in atexit+0x30 libCsup.so.1
#2 0x20000000760bc7c0:0 in init_once+0x1570 libdcekt.so.1
#3 0x2000000076d1b5e0:0 in pthread_once+0x350 libpthread.so.1
#4 0x20000000763943a0:0 in ptdexc_once+0x50 libdcekt.so.1
#5 0x20000000760bb230:0 in rpc__init+0x150 libdcekt.so.1
#6 0x20000000760a9e80:0 in rpc_string_binding_compose+0x70 /usr/lib/hpux32/libdcekt.so.1

info shared, after abort:
./librpcclient.so (shared library unloaded)
0x200000007688d000 0x200000007688dea0 0x200000007688c000 0x200000007688c0e0
/usr/lib/hpux32/libdcekt.so.1 (shared library unloaded)
0x2000000075f26000 0x2000000076885020 0x2000000075eb0000 0x2000000075f17338

(gdb) disas $pc-16*1 $pc+16*1
Dump of assembler code from 0x2000000076dc4f60:0 to 0x2000000076dc4f80:0:
0x2000000076dc4f60:0: (p1) ld8.s r8=[r9]
(gdb) p /x $r9
$1 = 0x2000000075ede1d8

If this answers your question you should see:
http://forums1.itrc.hp.com/service/forums/helptips.do?#33

[Grischa]

Thank you for you detailed answer.
HP-Support supposed to use linker flag -B nodelete to avoid that libdcekt is unloaded and the function registered in atexit becomes invalid. This is the solution for me, bacause I cannot force each module linking the rpc-client-library dynamically to link to libdcekt.

[Dennis Handly]

>HP-Support supposed to use linker flag -B nodelete

Yes, that option was added for libCsup.

[Grischa]

Thank you again for help. I close this thread now.

[Dennis Handly]

Of course if you have access to the source to libdcekt, you should probably remove the call to atexit and change it to have a fini function. That function can look at a flag to see if that pthread_once was done, then do what atexit would have done.

That way it gets done when the lib is unloaded and at exit time. The only issue I see is that the ordering may not be in the strict atexit order.

[Grischa]

Yes, this would be a solution, but then I have to maintain special versions of libdcekt and distribute it to customers.
Because I found no equal problem report like I had in web, I assume that loading libdcekt-bounded modules dynamically is not common, but to make live easier HP should take out this atexit registration and perform clanup-tasks by recogizing the unload like you described.