-
Bug
-
Resolution: Fixed
-
P2
-
hs25
-
b57
-
Not verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8027884 | 8 | Igor Veresov | P2 | Closed | Fixed | b115 |
JDK-8027997 | 7u60 | Igor Veresov | P2 | Closed | Fixed | b01 |
While running some benchmarks for a G1 fix I've gotten several crashes in Java code. The crashes seem to come right after encountering an unexpected ClassCastException. I believe that the cause for the exception is that the object reference we're trying to cast is a dead pointer into the heap since sometimes it's to an object of a completely wrong type and sometimes the pointer is in the middle of another object.
The main two stack traces I get are:
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v ~RuntimeStub::throw_class_cast_exception Runtime1 stub
J 5336 C1 org.spec.jbb.infra.txinjector.Driver$TokenPopulateTask.run()V (48 bytes) @ 0x00007ffb897e87e3 [0x00007ffb897e8140+0x6a3]
J 6363 C2 java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V (225 bytes) @ 0x00007ffb8a038238 [0x00007ffb8a037ce0+0x558]
J 4817 C1 java.util.concurrent.ThreadPoolExecutor$Worker.run()V (9 bytes) @ 0x00007ffb897c9d4c [0x00007ffb897c9c40+0x10c]
J 2907 C1 java.lang.Thread.run()V (17 bytes) @ 0x00007ffb8996f40c [0x00007ffb8996f2c0+0x14c]
v ~StubRoutines::call_stub
and: (where the top frame was deopted: reason=class_check action=maybe_recompile pc=0x00007fda217d6dc0 method=org.spec.jbb.infra.txinjector.Driver$ProbeTask.getRunTask()Ljava/lang/Runnable; @ 14)
j org.spec.jbb.infra.txinjector.Driver$ProbeTask.getRunTask()Ljava/lang/Runnable;+14
J 4283 C2 org.spec.jbb.core.scheduler.SingleLoopTimerScheduler$TimerTask.fire(J)V (48 bytes) @ 0x00007fda21d8e0b0 [0x00007fda21d8da00+0x6b0]
j org.spec.jbb.core.scheduler.SingleLoopTimerScheduler$TimerTask.run()V+15
J 4431 C1 java.lang.Thread.run()V (17 bytes) @ 0x00007fda21a793cc [0x00007fda21a79280+0x14c]
v ~StubRoutines::call_stub
I've also seen this crash in the GC code, also due to a broken object reference.
I can't reproduce this with hs25-b43 so I believe this is a fairly recent regression.
I've not been able to run jbb2013 with +Verify{Before,After}GC because the benchmark refuses to ramp up because it thinks the machine is too slow.
ILW=HMM => P2
The main two stack traces I get are:
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v ~RuntimeStub::throw_class_cast_exception Runtime1 stub
J 5336 C1 org.spec.jbb.infra.txinjector.Driver$TokenPopulateTask.run()V (48 bytes) @ 0x00007ffb897e87e3 [0x00007ffb897e8140+0x6a3]
J 6363 C2 java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V (225 bytes) @ 0x00007ffb8a038238 [0x00007ffb8a037ce0+0x558]
J 4817 C1 java.util.concurrent.ThreadPoolExecutor$Worker.run()V (9 bytes) @ 0x00007ffb897c9d4c [0x00007ffb897c9c40+0x10c]
J 2907 C1 java.lang.Thread.run()V (17 bytes) @ 0x00007ffb8996f40c [0x00007ffb8996f2c0+0x14c]
v ~StubRoutines::call_stub
and: (where the top frame was deopted: reason=class_check action=maybe_recompile pc=0x00007fda217d6dc0 method=org.spec.jbb.infra.txinjector.Driver$ProbeTask.getRunTask()Ljava/lang/Runnable; @ 14)
j org.spec.jbb.infra.txinjector.Driver$ProbeTask.getRunTask()Ljava/lang/Runnable;+14
J 4283 C2 org.spec.jbb.core.scheduler.SingleLoopTimerScheduler$TimerTask.fire(J)V (48 bytes) @ 0x00007fda21d8e0b0 [0x00007fda21d8da00+0x6b0]
j org.spec.jbb.core.scheduler.SingleLoopTimerScheduler$TimerTask.run()V+15
J 4431 C1 java.lang.Thread.run()V (17 bytes) @ 0x00007fda21a793cc [0x00007fda21a79280+0x14c]
v ~StubRoutines::call_stub
I've also seen this crash in the GC code, also due to a broken object reference.
I can't reproduce this with hs25-b43 so I believe this is a fairly recent regression.
I've not been able to run jbb2013 with +Verify{Before,After}GC because the benchmark refuses to ramp up because it thinks the machine is too slow.
ILW=HMM => P2
- backported by
-
JDK-8027884 G1: SPECjbb2013 crashes due to a broken object reference
-
- Closed
-
-
JDK-8027997 G1: SPECjbb2013 crashes due to a broken object reference
-
- Closed
-
- duplicates
-
JDK-8027216 Crash in Symbol::as_klass_external_name on OSX
-
- Closed
-
- relates to
-
JDK-8044090 C1: Old value instead of new one is passed to post-barrier in UnsafeGetAndSetObject
-
- Resolved
-
-
JDK-8027751 C1 crashes in Weblogic with G1 enabled
-
- Closed
-