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

panic in MarkSweep::follow_root during scavenge



    • Type: Bug
    • Status: Closed
    • Priority: P2
    • Resolution: Not an Issue
    • Affects Version/s: 1.3.1, 1.3.1_01, 1.4.0
    • Fix Version/s: None
    • Component/s: hotspot
    • Subcomponent:
    • CPU:
    • OS:


      Name: md23716 Date: 09/04/2001

      1. Basic Info:

      1.1 Platform (Solaris / Win32):


      1.2 Operating System Level/Version:


      1.3 Specific Sun Release Information:

      1.3.0_03 and 1.3.1-b24

      1.4 Known existing SUN Bug ID's (If Any):


      2. Workarounds:


      3. Test Case and Failure Data

      3.1 CRASH:

      3.1a Java Thread Stack Dump

      No Java thread dump is available as the JVM is embedded inside another process.

      3.1b C Stack Trace:

      # HotSpot Virtual Machine Error, Unexpected Signal 11
      # Please report this error at
      # http://java.sun.com/cgi-bin/bugreport.cgi
      # Error happened during: scavenge
      # Error ID: 4F533F534F4C415249530E4350500812 01
      # Problematic Thread: prio=5 tid=0x4f4060 nid=0x8 runnable

      [30] __libthread_segvhdlr(0xb, 0xfdf05638, 0xfdf05380, 0xfe86e000, 0xb, 0x0), at 0xfe8590c0
      [31] __sighndlr(0xb, 0xfdf05638, 0xfdf05380, 0xfe858fdc, 0xfdf05e10, 0xfdf05e00), at 0xfe85bc30
      [32] sigacthandler(0xb, 0xfdf05d78, 0xfdf05380, 0xfe86e000, 0xfdf05d78, 0xfdf05638), at 0xfe858434
      ---- called from signal handler with signal 11 (SIGSEGV) ------
      [33] MarkSweep::follow_root(0xfeb88258, 0xf3434588, 0x0, 0x0, 0x0, 0x0), at 0xfe9d4620
      [34] JNIHandleBlock::oops_do(0xfebb5eb0, 0xb5dcb8, 0xfeb795a0, 0x0, 0xb5dcb8, 0xfe9d44f8), at 0xfe96e840
      [35] JavaThread::oops_do(0xb0aae0, 0xfe9d44f8, 0x1068, 0x10, 0xfeb795a0, 0xfe9d44f8), at 0xfea5680c
      [36] Threads::oops_do(0xfeb795a0, 0xb0aae0, 0xfe9d44f8, 0xfe9d44f8, 0xeb610000, 0xf9761ffe), at 0xfea58f0c
      [37] MarkSweep::invoke_at_safepoint(0xfe9d44f8, 0xfeb8825c, 0xfeb88258, 0xfeb795a0, 0x4abb5ce6, 0x0), at 0xfe9d3a88
      [38] Scavenge::invoke_at_safepoint(0x1004, 0xfeb8cd00, 0xe930904c, 0xfeb8ccf8, 0xfeb795a0, 0xfebb5eb0), at 0xfea0bca8
      [39] VM_Operation::evaluate(0xe9309020, 0xfeb8f29c, 0xf0, 0xfdf05, 0xfeb795a0, 0xfdf05b44), at 0xfea6b8e8
      [40] VMThread::evaluate_operation(0x4f5f18, 0xe9309020, 0xfeb795a0, 0xfeb8c7c8, 0xfeb8912c, 0xfeb795a0), at 0xfea6aa28
      [41] VMThread::loop(0x4f5f18, 0xe9309020, 0x8, 0xfeb93a7c, 0xfeb93a70, 0xfeb93a80), at 0xfea6ada0
      [42] VMThread::run(0xfeb795a0, 0x4f5f18, 0x0, 0x0, 0x0, 0x0), at 0xfea6a838
      [43] _start(0xfeb795a0, 0xfe874798, 0x0, 0x5, 0x1, 0xfe401000), at 0xfe9f09e8

      3.1c Is Bug Reproducible with the application ?


      3.1d Is the application self-contained ?

      No, part of a multi process application server

      3.1e Java source files of application leading to crash

      Too many for this SUNBUG

      4. Targeted FCS Release


      5. Suggested Fix:

      5.1 Suggested Fix


      5.2 Documentation of how root cause of failure was determined


      5.3 Alternative Fix(es) considered/tested with pros and cons


      5.4 Results of IBM testing in application/customer environment


      5.5 Regression test run status/results


      5.6 JCK test run status



      ###@###.### 2001-10-26

      IBM have provided a testcase on a machine in the UK (inside SWAN) It uses their latest MQSeries code, which they have provided for us.
      I've run the testcase against Merlin (1.4), and an assertion was triggered,
      I then backported the assertion to 1.3.1, and again the assertion was triggered
      as follows...

      > > # HotSpot Virtual Machine Error, assertion failure
      > > # Please report this error at
      > > # http://java.sun.com/cgi-bin/bugreport.cgi
      > > #
      > > # Java VM: Java HotSpot(TM) Client VM (1.4.0-beta3-b84-debug mixed mode)
      > > #
      > > # assert(result != deleted_handle(), "Used a deleted global handle.")
      > > #
      > > # Error ID:
      > > /export/home3/jdk/jdk1.4/ws/hotspot/src/share/vm/runtime/jniHandles.hpp, 164 [
      > > Patched ]
      > > #
      > > # Problematic Thread: prio=5 tid=0x536410 nid=0x18 runnable
      > > #
      > > Dumping core....

      I asked IBM to check their code, as t he backtrace indicates that the problem originates in their code.

      current thread: t@26
      =>[1] __sigprocmask(0x0, 0xe7cfd1c0, 0x0, 0x0, 0x0, 0x0), at 0xfe959ab8
        [2] _resetsig(0xfe95c408, 0x0, 0x0, 0xe7d01d78, 0xfe96e000, 0x0), at 0xfe94e4fc
        [3] _sigon(0xe7d01d78, 0xfe9759a8, 0x6, 0xe7cfd294, 0xe7d01d78, 0x0), at 0xfe94dc9c
        [4] _thrp_kill(0x0, 0x1a, 0x6, 0xfe96e000, 0x1a, 0x0), at 0xfe950cb0
        [5] raise(0x6, 0x6, 0xe7cfd358, 0xfe96e000, 0x6, 0xe7cfd3f0), at 0xfeccafe0
        [6] abort(0xfed38018, 0xe7cfd3f0, 0x0, 0xfffffff8, 0x4, 0xe7cfd411), at 0xfecb577c
        [7] os::abort(0x1, 0xfe5683f8, 0xe7cfdc94, 0xfe672718, 0xfe6726b2, 0x0), at 0xfde193e8
        [8] report_error(0x1, 0xfe5b6d81, 0xa4, 0xfe568245, 0xfe568257, 0xfe5b6d66), at 0xfdade654
        [9] report_assertion_failure(0xfe5b6d66, 0xfe5b6d81, 0xa4, 0xfe5b6dc9, 0x3ccf00, 0xe7cfde4c), at 0xfdadd970
        [10] JNIHandles::resolve_non_null(0x330428, 0xfe5b3312, 0x0, 0xe7cfdf50, 0x1, 0x741c90), at 0xfdc5d0e0
        [11] jni_ReleaseIntArrayElements(0x37968c, 0x330428, 0x741c90, 0x0, 0x0, 0x330424), at 0xfdc4eb30
        [12] ImbPubSubJNIPubSubNode::checkRetPubDelivery(0x1854f0, 0xfa3f372e, 0xff25f984, 0xe7cfe5ac, 0xe7cfe10c, 0x38b4), at 0xfa1c98e8
        [13] ImbPubSubControlMessageHandler::processRetainedPublication(0xfa3d462e, 0xff25f984, 0x4000, 0x0, 0xfa42ecb8, 0x0), at 0xfa0d3aa4
        [14] ImbPubSubControlNode::registerSubscriber(0xff25f984, 0xe7d00c10, 0xe7cfff6c, 0x0, 0xff25f910, 0x0), at 0xfa0f470c
        [15] ImbPubSubControlNode::evaluate(0x29c718, 0xe7d00bf8, 0x29c7d4, 0xfed38018, 0x0, 0x0), at 0xfa0d8594
        [16] ImbDataFlowTerminal::evaluate(0xfeef8f04, 0xff25f984, 0x0, 0xffffffff, 0x20, 0x20), at 0xfee35db0
        [17] ImbDataFlowTerminal::propagate(0x29c588, 0xe7d00bf8, 0x29be68, 0x0, 0x34a768, 0x2dabb8), at 0xfee35ba4
        [18] ImbMqInputNode::readQueue(0x1c, 0x1c, 0x1c, 0x1c, 0xe8aeed38, 0x3f7358), at 0xe87fcbfc
        [19] ImbMqInputNode::Parameters::run(0x2ddaf0, 0x2dabb8, 0x2dac20, 0x4, 0x1f0b30, 0xfef54b74), at 0xe8824994
        [20] ImbThreadPoolThreadFunction::run(0x3f9c70, 0x2dabb8, 0xfef5743c, 0x0, 0x0, 0x0), at 0xff1c0374
        [21] ImbOsThread::threadRun(0x2dabb8, 0xfef6a118, 0x0, 0x0, 0x0, 0x0), at 0xff1b34f8
        [22] ImbOsThread::threadBootStrap(0x2dabb8, 0xfe8f5d18, 0x0, 0x5, 0x1, 0xfe401000), at 0xff1b35bc

      Here's the IBM reply

      > ----------------IBM reply -----------
      > IBM think this the assertion you found is a JNI bug and not a problem
      > with
      > their code - the assertion is triggered in jni_ReleaseIntArrayElements,
      > which
      > is called to release an array that the JNI should have "pinned" in memory
      > during a previous GetIntArrayElements call (see
      > http://java.sun.com/docs/books/tutorial/native1.1/implementing/array.html
      > for more details).
      > I have looked at the IBM code which issues these calls and they seem to
      > be correct, which suggests a possible problem with the JNI itself (?)
      > -------------end IBM reply -----------


          Issue Links



              foliversunw Fred Oliver (Inactive)
              mdevereuorcl Michelle Devereux (Inactive)
              0 Vote for this issue
              3 Start watching this issue