JVM crash in unit test DirectTest #24
Comments
|
Can't see how to attach a file here, so A fatal error has been detected by the Java Runtime Environment:SIGSEGV (0xb) at pc=0x00007f1db8bdbc71, pid=16855, tid=139765519607552JRE version: 6.0_26-b03Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode linux-amd64 compressed oops)Problematic frame:C [ld-linux-x86-64.so.2+0x9c71] _dl_rtld_di_serinfo+0x1141If you would like to submit a bug report, please visit:http://java.sun.com/webapps/bugreport/crash.jspThe crash happened outside the Java Virtual Machine in native code.See problematic frame for where to report the bug.--------------- T H R E A D --------------- Current thread (0x00000000413bb000): JavaThread "Finalizer" daemon [_thread_in_native, id=16865, stack(0x00007f1db215e000,0x00007f1db225f000)] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000028 Registers: Top of Stack: (sp=0x00007f1db225c640) Instructions: (pc=0x00007f1db8bdbc71) Register to memory mapping: RAX=0x0000000000000000 is an unknown value Stack: [0x00007f1db215e000,0x00007f1db225f000], sp=0x00007f1db225c640, free space=1017k Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) --------------- P R O C E S S --------------- Java Threads: ( => current thread ) Other Threads: VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap Code Cache [0x00007f1db3600000, 0x00007f1db3870000, 0x00007f1db6600000) Dynamic libraries: VM Arguments: Environment Variables: Signal Handlers: --------------- S Y S T E M --------------- OS:squeeze/sid uname:Linux 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:07:13 UTC 2011 x86_64 /proc/meminfo: CPU:total 4 (4 cores per cpu, 1 threads per core) family 16 model 2 stepping 3, cmov, cx8, fxsr, mmx, sse, sse2, sse3, popcnt, mmxext, 3dnow, 3dnowext, lzcnt, sse4a /proc/cpuinfo: processor : 1 processor : 2 processor : 3 Memory: 4k page, physical 7937084k(60648k free), swap 0k(0k free) vm_info: Java HotSpot(TM) 64-Bit Server VM (20.1-b02) for linux-amd64 JRE (1.6.0_26-b03), built on May 4 2011 01:13:47 by "java_re" with gcc 3.2.2 (SuSE Linux) time: Fri Sep 2 01:39:49 2011 |
|
It appears that the class loader is attempting to re-bind the Native.close() native method. If the VM were running parallel finalization threads, it's possible that the Native library could be unloaded/unbound before the static object within the Native class was finalized. There may still be an outstanding issue with finalizer-based calls to Native native calls, if the Native class can be made eligible for GC (and thus is possible to run its finalizer) before other finalizers (such as Memory) are run on GC'd objects. |
|
Might be related to this issue: http://bugs.sun.com/view_bug.do;jsessionid=3f513e6142c142209777e92736eb4?bug_id=4240589 |
|
@bhamail is this still an issue? I recently made some tweaks that resolve some direct-calling functionality |
|
Apparently there is still an issue. I then ran: ant test. This run had a bunch of failures and errors. Below is the direct-calling failure snippet: Other failures: and: and: I will try to attach the crash log. |
|
Here's a gist with the full crash log: |
|
More info: I re-ran: ant test, and got the same errors/failures as above. I then ran: ant clean dist test (same as the very first run), and the build succeeded, HOWEVER, I realized it lied: no unit tests were actually run: -setup: compile: javah: -native-api-check: :rsrc: rsrc: native: 🫙 jar: compile-tests: test: BUILD SUCCESSFUL Notice how 'test:' shows no unit tests, then the build ends. |
|
Good point. The callback cleanup failures are a known issue on linux/64 (and sometimes on windows/64). The direct test crash is of more interest; I haven't seen it on my linux64 setup. The callback cleanup failures aren't a serious worry; at worst you have old java Thread objects hanging around like before, or it's possible that the tests simply don't yet know how to trigger whatever it is within the VM that actually gets them GC'd. As far as I can tell the native threads are properly detached, making the Java Thread objects available for GC, even if that never actually happens within the tests. Note that these tests work for most other platforms. On Nov 28, 2012, at 11:35 PM, Dan Rollo wrote:
|
|
Callback failures have been addressed, please retest for other errors @bhamail |
|
This should be resolved with the disposal consolidation performed in the |
The VM error below has occurred twice so on my Ubuntu 10.04 amd64 machine.
Also, twice, the same test passed when I ran the test suite again.
I will attach hs_err_pid16855.log as well.
Dan Rollo
The text was updated successfully, but these errors were encountered: