Relates :
|
|
Relates :
|
|
Relates :
|
Nightly gc_baseline testing hit this, once. I've attached the full hs_err log. It looks to me like we ran out of space in the eden: eden space 4096K, 100% used [0x24250000, 0x24650000, 0x24650000) and started to come to a safepoint for a young generation collection: VM state:synchronizing (normal execution) .... VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) [0x002952d8/0x000016f8] Threads_lock - owner thread: 0x02a43c00 [0x00295458/0x000016bc] Heap_lock - owner thread: 0x02ea9400 but then one (of the many!) threads stumbled across an unexpected null pointer exception: # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x08173090, pid=16132, tid=20148 .... Current thread (0x02eab400): JavaThread "Thread-212" [_thread_in_vm, id=20148] siginfo: ExceptionCode=0xc0000005, reading address 0x00000000 That thread seems to be interpreting some code generated for reflection: Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j sun.reflect.GeneratedMethodAccessor19.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+212 j sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+111 j javasoft.sqe.javatest.lib.apitest.AssertionTest.runTest(Ljava/lang/Object;[Ljava/lang/Object;[I)Ljavasoft/sqe/javatest/Status;+111 J javasoft.sqe.javatest.lib.apitest.GridGenerator.executeTestCase([I)V j javasoft.sqe.javatest.lib.apitest.GridGenerator.iterate([Ljavasoft/sqe/javatest/lib/apitest/Factory;)V+65 j javasoft.sqe.javatest.lib.apitest.GridGenerator.run(Ljavasoft/sqe/javatest/lib/apitest/AssertionTest;[Ljavasoft/sqe/javatest/lib/apitest/Factory;)Ljavasoft/sqe/javatest/Status;+23 j javasoft.sqe.javatest.lib.apitest.AssertionTest.run([Ljava/lang/String;Ljava/io/PrintWriter;Ljava/io/PrintWriter;)Ljavasoft/sqe/javatest/Status;+86 j javasoft.sqe.stresstest.StressTest$TestThread.run()V+177 v ~StubRoutines::call_stub The other thing I notice is that all the Java threads are in _thread_blocked, except the thread that failed, which is =>0x02eab400 JavaThread "Thread-212" [_thread_in_vm, id=20148] If we'd gotten into the collection itself, I would take this as a GC bug. But since we haven't gotten to the collection yet, it's something else.
|