JVM 1.3.0.01 crash on HP-UX 11 using JNI; SIGBUS
I have a C++ program that uses JNI to make some calls into Java code. This program loads a shared library which in turn loads the JVM. This works alright on Solaris 8 SPARC using JRE 1.3.0, but not on HP-UX with JRE 1.3.0.01 - with either the classic or hotspot JVM. With either case, the JVM receives a SIGBUS (signal 10 - bus error), crashes, and takes down the entire process with it, leaving a huge core file.
Basic details and then I'll write more:
OS: HP-UX 11.00
JRE: 1.3.0.01
patches applied: (rather than listing them all, I'll just say that I applied all the required patches on HP's website prior to installation, plus PHSS_22514 for the issue of loading the HotSpot VM library from native code)
Architecture: using the PA-RISC 1.1 JVMs (tried both hotspot and classic VMs) on a PA-RISC 2.0 machine (need to make sure this will run on a PA-RISC 1.1 machine)
special JVM arguments: only -Xms=10m
to set the initial/minimum heap size.
I already tried a solution listed in a FAQ on HP's website for SIGBUS 10 and SIGSEGV 11 problems with JNI:
http://www.hp.com/products1/unix/java/java2/sdkrte1_3/faq.html#troubleshoot9
but this did not change my situation at all (and even if it did work, disabling JIT is not really a great solution... of course this would only work in the classic JVM anyway). The second part about doing DestroyJavaVM();
I didn't *think* was applicable in my situation because I'm initiaing JNI calls within a duration of the C++ side of the process that didn't complete yet.
Any ideas? I have a number of other things to try, such as using -Xnocatch
to produce a cleaner stack trace, a more recent JRE version, and recompiling all my native code with debug symbols and then really analyzing the situation with a debugger, but I thought I'd post this and see if anyone has encountered this before or has any other ideas.Thanks so much for any help you can give - I'm really in a bind with this one!
This will make the post pretty long, but I'll go ahead and include edited versions of the crash output.
** I know about the implict vs. explicit null check thing in the case of HotSpot, but I don't think this is the problem so far. Could still try recompiling my code with the -z
aCC compiler switch to see if anything else happens right away...
-
UsingHOTSPOT JVM:
... HotSpot VM warning: Disabling implicitnull checks.
Connecting...done.
Parsing file (blah blah)...
#
# Java version:
# HotSpot VM (mixed mode)
#
# HotSpot Virtual Machine Error, Unexpected Signal 10
#
# occurred at pc=c015ab94
# Error ID: /CLO/Components/JAVA_HOTSPOT/Src/build/hp-ux/../../src/os/hp-ux/vm/os_hp-ux.cpp, 2998
#
(snip): 21335 Abort(coredump)
UsingCLASSIC JVM:
Connecting...done.
SIGBUS10* bus error
Full thread dump Classic VM (jinteg:02/14/01-23:51,native threads):
"RMI ConnectionExpiration-[207.18.219.134:53824]" (TID:0x7c1cdd40, sys_thread_t:0x40430e40, stat
e:CW,native ID:0xa) prio=5
at java.lang.Thread.sleep(Native Method)
at sun.rmi.transport.tcp.TCPChannel$Reaper.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
"GC Daemon" (TID:0x7c1cbdd0, sys_thread_t:0x40390170, state:CW,native ID:0x9) prio=2
at java.lang.Object.wait(Native Method)
at sun.misc.GC$Daemon.run(Unknown Source)
"RMI RenewClean-[207.18.219.134:53824]" (TID:0x7c1cbc10, sys_thread_t:0x40386d50, state:CW, nati
ve ID:0x8) prio=5
at java.lang.Object.wait(Native Method)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
at sun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
"Thread-0" (TID:0x7c1c26b0, sys_thread_t:0x4001b820, state:R,native ID:0x1) prio=5
"JIT Compiler" (TID:0x7c1c14d0, sys_thread_t:0x400b5110, state:CW,native ID:0x7) prio=5
"Finalizer" (TID:0x7c1c1510, sys_thread_t:0x400b3818, state:CW,native ID:0x6) prio=8
at java.lang.Object.wait(Native Method)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
at java.lang.ref.Finalizer$FinalizerWorker$FinalizerThread.run(Finalizer.java:120)
"Reference Handler" (TID:0x7c1c12f8, sys_thread_t:0x400aeb88, state:CW,native ID:0x5) prio=10
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Unknown Source)
at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)
"Signal dispatcher" (TID:0x7c1c1328, sys_thread_t:0x400acba0, state:CW,native ID:0x4) prio=5
"main" (TID:0x7c1c11a8, sys_thread_t:0x400398b0, state:R,native ID:0x2) prio=5
Monitor Cache Dump:
java.lang.ref.ReferenceQueue$Lock@7C1C1520/7C3C4650: <unowned>
Waiting to be notified:
"Finalizer" (0x400b3818)
java.lang.ref.Reference$Lock@7C1C1308/7C3C4010: <unowned>
Waiting to be notified:
"Reference Handler" (0x400aeb88)
sun.misc.GC$LatencyLock@7C1CBE58/7C435168: <unowned>
Waiting to be notified:
"GC Daemon" (0x40390170)
java.lang.ref.ReferenceQueue$Lock@7C1CB8E8/7C432B88: <unowned>
Waiting to be notified:
"RMI RenewClean-[207.18.219.134:53824]" (0x40386d50)
Registered Monitor Dump:
JIT thread lock: <unowned>
Waiting to be notified:
"JIT Compiler" (0x400b5110)
utf8 hash table: <unowned>
JNI pinning lock 31: <unowned>
JNI pinning lock 30: <unowned>
JNI pinning lock 29: <unowned>
(snipped by author - goes all the way down to lock 0)
JNI pinning lock 1: <unowned>
JNI pinning lock 0: <unowned>
JNI global reference lock: <unowned>
BinClass lock: <unowned>
Class linking lock: <unowned>
Systemclass loader lock: <unowned>
Code rewrite lock: <unowned>
Heap lock: <unowned>
Monitor cache lock: owner"Thread-0" (0x4001b820) 1 entry
Thread queue lock: owner"Thread-0" (0x4001b820) 1 entry
Monitor registry: owner"Thread-0" (0x4001b820) 1 entry
Parsing file (blah blah)...: 29536 Abort(coredump)
