Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6224591

JVM stops merging state vectors for blocks where there's a monitor mismatch.

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P2
    • Resolution: Fixed
    • Affects Version/s: 1.3.1_13, 1.4.2_05
    • Fix Version/s: 6
    • Component/s: hotspot
    • Subcomponent:
    • Resolved In Build:
      b28
    • CPU:
      generic
    • OS:
      solaris_8

      Backports

        Description


        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

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  never Tom Rodriguez
                  Reporter:
                  kevinw Kevin Walls
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  4 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:
                    Imported:
                    Indexed: