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.