JDK-4397763 : JDWP/JVMDI: UnloadEvent- nsk JDI fields003 test causes crash of Ladybird HotSpot
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmdi
  • Affected Version: 1.3.1
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_7
  • CPU: sparc
  • Submitted: 2000-12-13
  • Updated: 2002-08-30
  • Resolved: 2002-08-30
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 :  
Relates :  
Relates :  
Description
Name: abR10010			Date: 12/13/2000


The nsk/jdi/ReferenceType/fields/fields003 test causes crash of 
the HotSpot Client VM (build 1.3.1beta-b11).

This test cheks the fields() method of the ReferenceType interface 
of the com.sun.jdi package for unloaded class.

The test loads a class, gets a ReferenceType instance for this
class, then enforces the class to be unloaded and calls the
equals() method - the com.sun.jdi.ObjectCollectedException
should be thrown in this case.
In fact, the HotSpot VM crashes while the test enforces the class
to be unloaded.

In order to unload the checked class the test causes the memory
exhausting so the GC would unload the checked class.

This failure happens on Solaris-Sparc.

The Merlin HotSpot VM (build 1.4beta-B44) passes this test.

To reproduce the bug on Solaris run doit.sh in
/net/sqesvr/export/vsn/GammaBase/Bugs/4397763.

The first parameter for doit.sh should be JDK root directory
(e.g. /java/jdk1.3.1/solsparc) and the other parameter(s) -
VM option(s) (optional).
  
See logs:

For Ladybird:

% doit.sh /export/java/dest/jdk1.3.1-b11/solsparc
java version "1.3.1beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1beta-b11)
Java HotSpot(TM) Client VM (build 1.3.1beta-b11, mixed mode)
==> nsk/jdi/ReferenceType/fields/fields003 test LOG:
--> test checks fields() method of ReferenceType interface 
    of the com.sun.jdi package for UNLOADED class

VirtualMachineManager: version 1.4
LaunchingConnector:
    name: com.sun.jdi.CommandLineLaunch
    description: Launches target using Sun Java VM command line and attaches to 
it
    transport: dt_socket
Arguments: {home=home=/net/java7/d/bond/java/dest/jdk1.3.1-b11/solsparc, 
vmexec=vmexec=java, options=options=, 
main=main=fields003a -vbs, quote=quote=", suspend=suspend=true}
--> fields003: fields003a debugee launched
**> fields003a: debugee started!
**> fields003a: waiting for "checked class dir" info...
--> fields003: debugee's "ready0" signal recieved!
--> fields003a: checked class loaded:fields003b
**> fields003a: waiting for "continue" or "quit" signal...
--> fields003: debugee's "ready1" signal recieved!
--> fields003: getting ReferenceType object for loaded checked class...
--> fields003: checked class FOUND: fields003b
--> fields003: waiting for "ready2" or "not_unloaded" signal from debugee...
**> fields003a: "continue" signal recieved!
**> fields003a: enforce to unload checked class...
##> fields003: UNEXPECTED debugee's signal (not "ready2")!
##> fields003: output from debugee:
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Error happened during: mark sweep
#
# Error ID: 53414645504F494E540E4350500113 01
#
# Problematic Thread: prio=5 tid=0x9f678 nid=0x4 runnable 
#

==> nsk/jdi/ReferenceType/fields/fields003 test FAILED

(Error ID: safepoint.cpp, 275)

NOTES.
    Sometimes the test hangs in the same place instead of
    causing crash of HotSpot VM.


For Merlin:


% doit.sh /export/java/dest/jdk1.4.0beta-b44/solsparc
java version "1.4.0beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0beta-b44)
Java HotSpot(TM) Client VM (build 1.4beta-B44, mixed mode)
==> nsk/jdi/ReferenceType/fields/fields003 test LOG:
--> test checks fields() method of ReferenceType interface 
    of the com.sun.jdi package for UNLOADED class

VirtualMachineManager: version 1.4
LaunchingConnector:
    name: com.sun.jdi.CommandLineLaunch
    description: Launches target using Sun Java VM command line and attaches to 
it
    transport: dt_socket
Arguments: {home=home=/net/java7/d/bond/java/dest/jdk1.4.0beta-b44/solsparc, 
vmexec=vmexec=java, options=options=, 
main=main=fields003a -vbs, quote=quote=", suspend=suspend=true}
--> fields003: fields003a debugee launched
**> fields003a: debugee started!
**> fields003a: waiting for "checked class dir" info...
--> fields003: debugee's "ready0" signal recieved!
--> fields003a: checked class loaded:fields003b
**> fields003a: waiting for "continue" or "quit" signal...
--> fields003: debugee's "ready1" signal recieved!
--> fields003: getting ReferenceType object for loaded checked class...
--> fields003: checked class FOUND: fields003b
--> fields003: waiting for "ready2" or "not_unloaded" signal from debugee...
**> fields003a: "continue" signal recieved!
**> fields003a: enforce to unload checked class...
**> fields003a: checked class unloaded!
**> fields003a: waiting for "quit" signal...
--> fields003: debugee's "ready2" signal recieved!
--> fields003: check that checked class has been unloaded realy...
--> fields003: checked class has been unloaded realy: fields003b
--> fields003: check ReferenceType.fields() method for unloaded class...
--> fields003: PASSED: expected Exception thrown - 
com.sun.jdi.ObjectCollectedException
--> fields003: waiting for debugee finish...
**> fields003a: "quit" signal recieved!
**> fields003a: completed!
--> fields003: expected Debugee's exit status - 95

==> nsk/jdi/ReferenceType/fields/fields003 test PASSED


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

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

PUBLIC COMMENTS .
10-06-2004

EVALUATION daniel.daugherty@Eng 2001-02-02 This assertion was triggered during a thread state transition from _thread_in_native to _thread_in_vm. The assertion verifies that the calling thread is indeed in the "from" state (_thread_in_native) and, and in this case, the thread state is _thread_blocked. Here is the interesting part of the stack: [11] ThreadInVMfromNative::ThreadInVMfromNative(this = 0xef20b3c0, thread = 0x3a330), line 154 in "interfaceSupport.hpp" [12] jni_ExceptionOccurred(env = 0x3a3c8), line 295 in "jni.cpp" dbx: warning: can't find file "/usr/re/jdk/jdk1.3.1/ws/make/../build/solaris-sparc/tmp/jpda/jdwp/obj_g/eventHandler.o" [13] eventHook(0x3a3c8, 0xef20b4f0, 0x3a330, 0x709af47e, 0x0, 0xef20b578), at 0xedebe070 [14] JvmdiInternal::post_proxy_event(jvmdi_e = CLASS, jthread = 0x3a330), line 1815 in "jvmdi.cpp" [15] jvmdi::post_class_unload_event(klass = 0xe88c8b50), line 3451 in "jvmdi.cpp" [16] SystemDictionary::follow_roots_phase2(), line 870 in "systemDictionary.cpp" The eventHook() method calls into the agent's event handler which has made a call to jni_ExceptionOccurred(). jni_ExceptionOccurred()'s prologue (in the JNI_ENTRY macro) tries to transition the thread from _thread_in_native to _thread_in_vm. However, the thread we are using to associate with the CLASS_UNLOAD event is actually blocked. I suspect that associating a thread with the CLASS_UNLOAD event is going to be at the root of the problem. daniel.daugherty@Eng 2001-02-02 I noticed a difference between JvmdiInternal::post_proxy_event() and JvmdiInternal::post_event(). post_event() transitions the thread from _thread_in_vm to _thread_in_native and post_proxy_event() does not. Could it be that simple? After some coding and testing...no it isn't that simple. Yes, post_proxy_event() should be setting the JavaThread's state so that the call to the agent starts with the proper thread state, i.e., _thread_in_native. However, there isn't a ThreadStateTransition object type to do this. Nor do I think there should be for this very special case. Okay. We can get the thread into the right state, but because we are in the middle of a GC, the agent is very limited in what it can do. If the agent calls into the VM at this point, then the VM will detect that we are at a safepoint and try to save the thread's state in preparation for stopping the thread at a safepoint. In this case, the agent is calling jni_ExceptionOccurred() and that is going to cause the agent to stall at a safepoint. Begin - robert.field@Eng 2001-02-09 Have a fix for the back-end agent. Instead of processing the event in a state where almost nothing can be safely done, the back-end simply notes that an unload has occurred; then the next time any other kind of event occurs, the back-end, which has been tracking loaded (prepared) classes, compares the current classes against its list to figure out what classes have been unloaded; it then synthesizes ClassUnloadEvents for them. Fix is being reviewed. End - robert.field@Eng 2001-02-09 Begin - robert.field@Eng 2001-02-12 Above fix has been reviewed and approved. Fix putback to service workspace. End - robert.field@Eng 2001-02-12
09-02-2001