JVM exit handler - for jvm invoked thro' native C

Question

complicated, atleast for me :) where do I find if JVM installs any exit handlers when invoked through native C app.
OS -> HP UX 11
java -version ->
java version "1.4.0.02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0.02-021031-18:00)
Java HotSpot(TM) Server VM (build 1.4 1.4.0.02-021031-19:15-PA_RISC2.0 PA2.0, mixed mode)
Although jvm used is HP's hotspot, behaviour seems to be generic, so any directions are appreciated.
In my case JNI based native shared object (on ux) is being used as a pluggin for comm with microsoft SQL2k.
A daemon loads the pluggin (shl_load) -> transaction -> unloads (shl_unload) pluggin.
For each tran I need to create a new JVM instance and later distroy it as it is not possible to multiple times create and distroy JVM in same process space (as encountered)
LD_PRELOAD=.../libjvm.sl
start the daemon( basic signals masked)
Parent -> fork() a child process and wait for its exit status.
Child -> Load JVM and execute reqd method
Child -> unload JVM
Child -> exit() the child process
Parent ->Check the child process exit() code and carry further processing.
Sometimes child does not exit cleanly. Even after exit() child process can be seen in process table and parent wait()'s idefinetly for child exit code.
gdb ouput of child preocess
#0 0xdd28ca38 in os::report_fatal_error () from /opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl
#1 0xdd28dc48 in os::handle_unexpected_exception ()
from /opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl
#2 0xdd296c50 in os::Hpux::JVM_handle_hpux_signal ()
from /opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl
#3 0xdd293adc in os::Hpux::signalHandler ()
from /opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl
#4 <signal handler called>
#5 0x7e5e6134 in ?? ()
#6 0xc03c6fbc in __niamHelper () from /usr/lib/libCsup.2
Can any one tell me what exactly is happening ?
If I call [b]_exit() instead of exit() everything works fine.

Answer 1

Thnx a lot,
     Finally I was able to locate atexit()'ed function which was causing the problem (setting br at exit() was not working, execution straightway stopped at #0)
(gdb) thr 1
[Switching to thread 1 (system thread 17555)]
(gdb) bt
#0 0x7e6224e0 in epc_exit_handler () from /citisafe/users/yogiraj/cs35/dll/ora_tcp.sl
#1 0xc03c6fbc in __niamHelper () from /usr/lib/libCsup.2
#2 0xc03c7110 in niambody () from /usr/lib/libCsup.2
#3 0xc03c721c in _niam () from /usr/lib/libCsup.2
#4 0xc016fe20 in exit () from /usr/lib/libc.2
#5 0xc4f0c364 in sql_exec_custStrProc () from /citisafe/users/yogiraj/cs35/lib/libtcsql.sl
#6 0x7ec0c9f4 in exec_ext_mgmt (p_ExtCredentials=0x7edf2878)
at /citisafe/users/yogiraj/cs35/c/sql_app.c:251
#7 0x9620 in adm_process_rec ()
#8 0x8bc8 in process_pwd_requests ()
#9 0x8684 in adm_do_ext_sync ()
#10 0x7f5c in main ()
Oracle client lib was the culprit.     Daemon is basically a 'C' daemon which loads pluggins for communication with various DB's including Oracle, Sybase, MS SQL etc and later unloads them on completion.
Ora lib libclntsh.sl installed "epc_exit_handler", eventhough we had shl_unload()'ed oracle pluggin earlier the handler refrence was still around. Later when process exit()'ed may be static dealloaction mech panicked.
Above exit() handler execution even after unloading of Oracle libs seems to be a known bug and work around suggested is to LD_PRELOAD=%ORALIB/libclntsh.sl. After LD_PRELOAD'ing exit() works fine.