JVM exit handler - for jvm invoked thro' native C

[yogiraj]

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
#5 0x7e5e6134 in ?? ()
#6 0xc03c6fbc in __niamHelper () from /usr/lib/libCsup.2
###########
Can any one tell me what exactly is happening ?

If I call _exit() instead of exit() everything works fine.

[Stephen Keane]

If you call _exit() instead of exit() then any functions registered though atexit() are not called, so maybe your problem is that a function has been registered via atexit() and it is this function that is causing the problem?

The other thing to consider is whether the Java application is using threads?

Also look at the signal handling scheme used in the C code.

[Steve Steel]

Hi


I saw something similar once and it was solved by the latest linker patch

For 11.00
Patch Name: PHSS_30969

Patch Description: s700_800 11.00 ld(1) and linker tools cumulative patch

Creation Date: 05/01/25

Post Date: 05/01/26

Hardware Platforms - OS Releases:
s700: 11.00
s800: 11.00

For 11i

Patch Name: PHSS_30970

Patch Description: s700_800 11.11 ld(1) and linker tools cumulative patch

Creation Date: 05/01/25

Post Date: 05/01/28

Hardware Platforms - OS Releases:
s700: 11.11
s800: 11.11

Products: N/A


Steve Steel

[yogiraj]

Thnkx Stephen,
Unfortunately Hp nor Sun is telling what are the atexit()'ed handlers registered by libjvm.sl.
As for threads, I don't create any but JVM does create 8 threads internally in libjvm.sl (could be seen in _ksleep thro' gdb)

Thnx Steve,
Patch does seem to be relevant in this case, I'll ask SA to apply and post the results.

[yogiraj]

hi,
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 _niam_body () 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.

[yogiraj]

Run GDB, set br at exit(), try to find various exit handler being called.
If anyone of them is currently not accesible (unmapped) runtime will generate SIGSEGV. But un/fortunately JVM internally uses SEGV and signal instead of being delivered to actual process is internally caught by JVM. Processing of which though fails and results into stacktrace something like one posted in first frame.

Thnx & Regds
Yogi