JDK-5056613 : unexpected exception/exception catch events in nsk cm03t001
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 5.0,9
  • Priority: P4
  • Status: Resolved
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2004-06-02
  • Updated: 2023-12-13
  • Resolved: 2014-09-25
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
tbdResolved
Related Reports
Relates :  
Description

Name: dd4877			Date: 06/02/2004



nsk/jvmti/scenarios/capability/CM03/cm03t001

       This test failed due to the wrong number of ExceptionEvents
       and ExceptionCatchEvents on Linux IA64 Server VM. This failure
       occurred on machine qeia2two.
                                                                               
       This failure is covered by the following bug:
           5023643 3/3 Crashes in GCBasher
       which is in state fixed. This fix is targeted for Tiger-B54.
                                                                               
       Update: service_hs_baseline was synced with main/baseline in
           time for this test run so we have the fix for 5023643.
       Update: This test failed on the 2004.05.27 run on Win-IA64
           Server VM. When this failure had first appeared, Swamy filed
           the following bug:
               5019035 4/4 unexpected exception/exception catch events
                           in nsk cm03t001
           Swamy's bug was closed as a duplicate of the following bug:
               4991286 4/4 thread misses ThreadDeath of StopThread on
                           Server VM
           4991286 was closed as a duplicate of:
               5023643 3/3 Crashes in GCBasher

Steve G. believes that 5019035 and 4991286 have nothing to do with
5023643. I'm filing a new bug to redocument the failure info.


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

Comments
Both tests cm01t007 and cm03t001 has race errors. It gives different error messages, but the cause is bad sync between jvmti thread and debuggee thread.
25-09-2014

Reproduced on Hudson during test stabilisation on Windows-x64, running all JVMTI test with concurrency=16 windows-x86/ws/product/build/bvt/images/j2sdk-image/lib/tools.jar [2014-02-14T07:09:18.66] export CLASSPATH [2014-02-14T07:09:18.66] PATH="${PATH}${PS}${LD_LIBRARY_PATH}" [2014-02-14T07:09:18.66] # Actual: PATH=C:/cygwin/bin;C:/cygwin/usr/bin;C:\WINDOWS/system32;C:/cont-test/jvmti-windows-x86/ws/product/build/bvt/images/j2sdk-image/bin;C:/cont-test/jvmti-windows-x86/ws/product/build/bvt/images/j2sdk-image/jre/bin/server;C:/cont-test/jvmti-windows-x86/ws/product/build/bvt/images/j2sdk-image/jre/bin;C:/cont-test/jvmti-windows-x86/ws/tests/vm/bin/lib/windows-amd64/nsk/jvmti/scenarios/capability/CM03; [2014-02-14T07:09:18.66] export PATH [2014-02-14T07:09:18.66] ${JAVA} ${JAVA_OPTS} ${EXECUTE_CLASS} ${TEST_ARGS} [2014-02-14T07:09:18.66] # Actual: C:/cont-test/jvmti-windows-x86/ws/product/build/bvt/images/j2sdk-image/bin/java -server -agentlib:cm03t001=-waittime=5 nsk.jvmti.scenarios.capability.CM03.cm03t001 [2014-02-14T07:09:24.99] # ERROR: cm03t001.c, 672: NSK_CPP_STUB2(PopFrame, jvmti, thread) [2014-02-14T07:09:24.99] # jvmti error: code=32, name=JVMTI_ERROR_OPAQUE_FRAME [2014-02-14T07:09:24.99] # Test level exit status: 97 # Host info: CYGWIN_NT-5.2-WOW64 STH-VMTESTBASE- 1.7.27(0.271/5/3) 2013-12-09 11:57 i686 Cygwin
14-02-2014

This is a very old bug. The issue can be not reproducible now.
21-08-2013

PUBLIC COMMENTS Name: dd4877 Date: 06/02/2004 . ======================================================================
24-07-2004

EVALUATION One serious testcase bug I found while investigating this is many static vars used for thread synchronization are not MT - safe. Following vars in file nsk/share/jvmti/agent_tools.c static volatile int agentStatusUpdated = NSK_FALSE; static volatile int syncFirst = NSK_TRUE; static volatile int syncPermit = NSK_FALSE; static volatile int syncSuspended = NSK_TRUE; few other vars need to be made MT safe. May be this is causing the intermittent exception miss. May be this synchronization problem is the cause of unexpected exception. This could be a test case bug. So this bug is not very critical to the tiger exit criteria. -Swamy BEGIN ::: ###@###.### 2004-07-01 It is very interesting case. In jvmtiEnter code we check to see if the thread is alive using following test: java_thread = java_lang_Thread::thread(thread_oop); if (java_thread == NULL) { return JVMTI_ERROR_THREAD_NOT_ALIVE; } In this case it has returned non null for java_thread so thread is still alive. But in VM_ThreadStop::doit() following statement returns NULL for target. ==> JavaThread* target = java_lang_Thread::thread(target_thread()); If the target thread is NULL we ignore it and just return the JVMTI_ERROR_NONE. So in this time interval the thread might have exited and that can happen if synchronization of threads is not done right in the test case. One problem is synchronization in test case and another problem we need to think is whether we should return error for this case. END ::::: ###@###.### 2004-07-01 BEGIN:::: ###@###.### 2004-07-23 Added more debug statement and I see race condition b/w the ThreadStop request and thread exit. So there is a window where thread could die before thread stop request is completed. When this happens no ThreadDeath event is delivered. So there are two problems here. 1. race condition in a test case and it should make sure thread has not exited. 2. ThreadStop should return NOT_ALIVE if the thread dies in the middle of ThreadStop operation. END:::: ###@###.### 2004-07-23
23-07-2004