Bug ID: JDK-4333847 test mncntenter001 causes hotspot intermittently hangs

JDK-4333847 : test mncntenter001 causes hotspot intermittently hangs

Type: Bug
Component: vm-legacy
Sub-Component: jvmpi
Affected Version: 1.3.0

Priority: P3
Status: Closed
Resolution: Fixed
OS: solaris_7
CPU: sparc

Submitted: 2000-04-27
Updated: 2021-03-01
Resolved: 2002-08-30

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other	Other
1.3.1 rc1Fixed	1.4.0Fixed

Related Reports

Relates :	JDK-4305128 - VM deadlocks during shutdown
Relates :	JDK-4430453 - Linux: SuspendCheckerThread doesn't timeout
Relates :	JDK-4413752 - Linux: suspended thread blocks raw ObjectMonitor entry
Relates :	JDK-8257831 - Suspend with handshakes

Description


Name: icR10030			Date: 04/27/2000


The Hotspot VM both build 1.3.0-B and build 1.3-b12 for Solaris 
(both java and java_g) intermittently fails the test
        nsk/jvmpi/events/mncntenter001
from
        testbase_nsk

To reproduce the bug run Korn shell script
        doit.ksh <jdk_root_directory> 
in
        /net/sqesvr/vsn/GammaBase/Bugs/<this bug number>

The script produces the output:
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-B)
Java HotSpot(TM) Client VM (build 1.3.0-B, interpreted mode)
------------------------ java -------------------------------
/export/ld24/java/hotspot/jdk1.3.0/solaris/bin/java -Xrunmncntenter001 
mncntenter001
------------ JVMPI_EVENT_JVM_INIT_DONE ------------
########### threads count: 32 ############
Event: JVMPI_EVENT_GC_START
Event: JVMPI_EVENT_GC_FINISH
Try suspend threads
Event: JVMPI_EVENT_MONITOR_CONTENDED_ENTER
Record type: JVMPI_GC_INSTANCE_DUMP(dump of a normal object), jobjectID: 
0xF99687C0
...
...
Event: JVMPI_EVENT_MONITOR_CONTENDED_ENTER
Record type: JVMPI_GC_INSTANCE_DUMP(dump of a normal object), jobjectID: 
0xF9971D78
Check threads's states
OK
Event: JVMPI_EVENT_GC_START
Event: JVMPI_EVENT_GC_FINISH
------------ JVMPI_EVENT_JVM_SHUT_DOWN ------------
exit 95
------------------------ java_g ---------------------------------
/export/ld24/java/hotspot/jdk1.3.0/solaris/bin/java_g -Xrunmncntenter001 
mncntenter001
------------ JVMPI_EVENT_JVM_INIT_DONE ------------
########### threads count: 32 ############
Event: JVMPI_EVENT_GC_START
Event: JVMPI_EVENT_GC_FINISH
Try suspend threads
Event: JVMPI_EVENT_MONITOR_CONTENDED_ENTER
Record type: JVMPI_GC_INSTANCE_DUMP(dump of a normal object), jobjectID: 
0xF91687D0
...
...
Event: JVMPI_EVENT_MONITOR_CONTENDED_ENTER
Record type: JVMPI_GC_INSTANCE_DUMP(dump of a normal object), jobjectID: 
0xF916CF48
OK
Event: JVMPI_EVENT_GC_START
Event: JVMPI_EVENT_GC_FINISH
########### threads count: 128 ############
Event: JVMPI_EVENT_GC_START
Event: JVMPI_EVENT_GC_FINISH
Try suspend threads
Event: JVMPI_EVENT_MONITOR_CONTENDED_ENTER
Record type: JVMPI_GC_INSTANCE_DUMP(dump of a normal object), jobjectID: 
0xF916BE48
...
...
Event: JVMPI_EVENT_MONITOR_CONTENDED_ENTER
Record type: JVMPI_GC_INSTANCE_DUMP(dump of a normal object), jobjectID: 
0xF9170C48
...
...
hangs...

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

Comments

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: ladybird FIXED IN: ladybird-rc1 INTEGRATED IN: ladybird-rc1 merlin-beta VERIFIED IN: merlin-rc1

14-06-2004

EVALUATION karen.kinnear@East 2000-08-14 With initial suspend/resume fix, this hung much later. Expectation is that this will at least require the extended cleanup related to suspend/resume. daniel.daugherty@Eng 2001-02-13 The current failure mode is due to a "suspended" thread acquiring an ObjectMonitor. daniel.daugherty@Eng 2001-03-06 Stress testing revealed additional problems: - JVM/PI SuspendThread now suspends threads in state _thread_in_native immediately. This causes problems with: java -XX:+SafepointALot -Xrunhprof:cpu=samples PepTest Karen encountered this problem on Win32. The cause is a deadlock between the VMThread deleting a VM_ThreadSuspend object and the suspended thread holding the Win32 equivalent of the malloc_lock - Every so often a VM_ThreadSuspend operation doesn't happen. This confuses the agent because suspend is assumed to work. The cause is an internal suspend/resume operation erasing the flags set by the VM_ThreadSuspend operation.

11-06-2004

SUGGESTED FIX daniel.daugherty@Eng 2001-02-12 Change the contended monitor acquisition code to not acquire a monitor when the thread is suspended. This will give us the following semantics for monitor enter and suspend: suspend before monitor enter - monitor not entered, thread suspended suspend during non-contended enter - monitor entered, thread suspended on return from VM transition suspend during contended enter - monitor not entered (due to contention), thread suspended The actual implementation will likely be a loop in the contended monitor case. Once a thread gets a contended monitor it checks to see if it is supposed to be suspended. If it is, then the monitor is exited, a yield like operation is done to give another thread a chance to enter the monitor, and the thread will attempt to reenter the monitor (and block). So the thread won't really be suspended, but it will remain blocked. daniel.daugherty@Eng 2001-03-06 To fix the memory allocation deadlock, add a SuspendCheckerThread that the VMThread can use to see if the current VM_ThreadSuspend operation will result in deadlock. The SuspendCheckerThread replaces the temporary fix put into place for Solaris via the following bug: 4305128 4/4 VM deadlocks during shutdown To fix the lost suspend, refactor suspend/resume into external and internal suspend/resume.

11-06-2004