JDK-6409422 : EXCEPTION_ACCESS_VIOLATION coming to a safepoint?
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-04-06
  • Updated: 2012-10-08
  • Resolved: 2006-08-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b96Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
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.

Comments
EVALUATION In klassItable::initialize_itable_for_interface() an interior oop pointer was being held across a potential GC point. The fix is to use the holder klass handle and an offset value to calculate the itable method entry pointer each time through the loop, instead of incrementing an absolute address.
31-07-2006