Name: md23716 Date: 09/04/2001

1. Basic Info:

1.1 Platform (Solaris / Win32):

Solaris

1.2 Operating System Level/Version:

5.8

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):

None

2. Workarounds:

None

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 ?

Yes

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

1.3.0_05

5. Suggested Fix:

5.1 Suggested Fix

Unknown

5.2 Documentation of how root cause of failure was determined

N/A

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

N/A

5.4 Results of IBM testing in application/customer environment

N/A

5.5 Regression test run status/results

N/A

5.6 JCK test run status

N/A

======================================================================

###@###.### 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
(/opt/SC5.0/bin/../WS5.0/bin/sparcv9/dbx)


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 -----------