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

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

    XMLWordPrintable

    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: