Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2125304 | 5.0u4 | Tom Rodriguez | P2 | Closed | Fixed | b03 |
JDK-2123081 | 1.4.2_09 | Chris Phillips | P2 | Closed | Fixed | b01 |
JDK-2123207 | 1.3.1_16 | Chris Phillips | P2 | Closed | Fixed | b01 |
JVM crash during GC: Oop wrongly followed as reference
The JVM is crashing during GC, even in interpreted mode (-Xint). For a certain application it is readily reproducible, and when using -XX:+VerifyBeforeGC in a debug VM (java_g) it can be seen crashing before the first GC (ie. heap is not corrupt).
In the customer case, the problem is seen with an obfuscated class, and has not been seen with non-obfuscated classes.
Stack is as follows (not using VerifyBeforeGC):
---- called from signal handler with signal 10 (SIGBUS) ------
[12] libjvm_g.so:oopDesc::mark(0x3, 0x3, 0x6, 0x1d0508, 0x21, 0xfd6811b8), at 0xfdc8600c
[13] libjvm_g.so:oopDesc::is_forwarded(0x3, 0x3, 0xc2e01004, 0x1, 0x0, 0x0), at 0xfdc84e18
[14] libjvm_g.so:FastScanClosure::do_oop(0xfd681638, 0xc2e00ffc, 0xc50, 0xfd6811ac, 0xfffffff8, 0xf6b70), at 0xfdc874b8
[15] libjvm_g.so:InterpreterFrameClosure::offset_do(0xfd6811c4, 0x1a, 0xc50, 0xfd6811ac, 0x1, 0x0), at 0xfdcb9054
[16] libjvm_g.so:InterpreterOopMap::iterate_oop(0xfd6811ac, 0xfd6811c4, 0xfd6811ac, 0xa, 0xfd681638, 0x0), at 0xfdfe6ca8
[17] libjvm_g.so:frame::oops_interpreted_do(0xfd6812c4, 0xfd681638, 0xfd6812d8, 0x0, 0x0, 0x0), at 0xfdcb2d80
[18] libjvm_g.so:frame::oops_do(0xfd6812c4, 0xfd681638, 0xfd6812d8, 0x0, 0x0, 0x0), at 0xfdcb361c
[19] libjvm_g.so:JavaThread::oops_do(0x23c740, 0xfd681638, 0x0, 0x0, 0x0, 0x0), at 0xfe1680f8
[20] libjvm_g.so:Threads::oops_do(0xfd681638, 0x1, 0x0, 0x0, 0x0, 0x0), at 0xfe16c614
[21] libjvm_g.so:GenCollectedHeap::process_strong_roots(0xcb068, 0x0, 0x1, 0x0, 0x1, 0xfd681614), at 0xfdcd57c0
[22] libjvm_g.so:DefNewGeneration::collect(0xcb478, 0x0, 0x0, 0x2004, 0x0, 0x0), at 0xfdc80b00
[23] libjvm_g.so:GenCollectedHeap::do_collection(0xcb068, 0x0, 0x0, 0x2004, 0x0, 0x0), at 0xfdcd5054
[24] libjvm_g.so:TwoGenerationCollectorPolicy::satisfy_failed_allocation(0xcabe0, 0x2004, 0x0, 0x0, 0xc2b8062c, 0x0), at 0xfdbdc52c
[25] libjvm_g.so:GenCollectedHeap::satisfy_failed_allocation(0xcb068, 0x2004, 0x0, 0x0, 0xc2b8062c, 0x0), at 0xfdcd5604
[26] libjvm_g.so:VM_GenCollectForAllocation::doit(0xc2b80610, 0xf6668, 0x0, 0xff37e000, 0xfd681e14, 0xfd681e04), at 0xfe2070e8
[27] libjvm_g.so:VM_Operation::evaluate(0xc2b80610, 0x1, 0x2710, 0x0, 0x4, 0xfd681e04), at 0xfe206a28
[28] libjvm_g.so:VMThread::evaluate_operation(0xf6668, 0xc2b80610, 0xfe418639, 0x0, 0x4, 0xff37e000), at 0xfe2026bc
[29] libjvm_g.so:VMThread::loop(0xf6668, 0x40, 0x40, 0x0, 0x4, 0xff37e000), at 0xfe202de0
[30] libjvm_g.so:VMThread::run(0xf6668, 0x40, 0xff37e000, 0xfd681d08, 0x4, 0x0), at 0xfe2023b4
[31] libjvm_g.so:_start(0xf6668, 0xff37f690, 0x1, 0x1, 0xff37e000, 0x0), at 0xfdffc3a4
###@###.### 2005-2-02 15:34:00 GMT
- backported by
-
JDK-2123081 JVM stops merging state vectors for blocks where there's a monitor mismatch.
- Closed
-
JDK-2123207 JVM stops merging state vectors for blocks where there's a monitor mismatch.
- Closed
-
JDK-2125304 JVM stops merging state vectors for blocks where there's a monitor mismatch.
- Closed