JDK-4628003 : JDI testcase filter_rt001 failing
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 1.4.0,1.4.2,5.0,6,9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2002-01-24
  • Updated: 2020-10-14
  • Resolved: 2014-10-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.
JDK 8 JDK 9
8-poolUnresolved 9 b05Fixed
Related Reports
Relates :  
Relates :  
Description
Testcase :
nsk/jdi/StepRequest/addClassFilter_rt/filter_rt001

Failing on all platforms. 
LOG:
/net/alpheridies.sfbay/export/VM/merlin/merlin-nightly/DTF-workspace/exec1/NIGHTLY-Serv_Baseline-ClientVM-JDI_FULLLOOK-comp-Solsparc-starwars-2002-01-23-PM-20-36-38-0665/jdk/solsparc/bin/java -client -Xcomp nsk.jdi.ClassPrepareRequest.addClassFilter_rt.filter_rt001 -arch=sparc -waittime=2 -debugee.vmkind=java "-debugee.vmkeys=-client -client -Xcomp"
##Exit status of execution step=95


Note: No output written.. 

Name: dkR10014			Date: 01/28/2002



The test fails only when debuggee class (filter_rt001a class) is running
on Client VM in -Xcomp mode. The test passes in other modes including when 
debuggee is running on Server VM in -Xcomp mode.
The failure is observed on Solaris sparc 5.7, Solaris x86 5.8, 
Linux RedHat 6.2.

The test checks that results of the method
 com.sun.jdi.StepRequest.addClassFilter(ReferenceType)
complies with its spec.

The test checks up on the following assertion:
  Restricts the events generated by this request to those 
  whose location is in the given reference type or any of its subtypes.				
	<BR>

The debugger class (filter_rt001 class) creates StepRequest filtered 
to only debuggee's TestClass10 class and then waits for StepEvent.
Please see detailed description of test case algorithm in header comment
of filter_rt001.java file. 

Below is part of failure test log:

#debugee.stderr> **> debuggee: debuggee started!
#debugee.stderr> **> debuggee:   'run': enter  :: threadName == thread1
#debugee.stderr> **> debuggee:   'run': enter  :: threadName == thread2
#debugee.stderr> **> debuggee: methodForCommunication();----1
#
#==> nsk/jdi/StepRequest/addClassFilter_rt/filter_rt001 :::::: case: # 0
#--> debugger: ......setting up StepRequest:
#--> debugger:        thread: instance of 
nsk.jdi.StepRequest.addClassFilter_rt.Thread1filter_rt001a(name='thread1', id=77); 
property: StepRequest1
#--> debugger:       StepRequest has been set up
#--> debugger: ......waiting for StepEvent in expected thread
#debugee.stderr> **> debuggee: entered: m11
#debugee.stderr> **> debuggee: entered: m10
#debugee.stderr> **> debuggee:   'run': exit   :: threadName == thread1
#debugee.stderr> **> debuggee: entered: m21
#debugee.stderr> **> debuggee: entered: m20
#debugee.stderr> **> debuggee:   'run': exit   :: threadName == thread2
#debugee.stderr> **> debuggee: methodForCommunication();
## ERROR: ##> debugger: ERROR: new event is not StepEvent
#--> debugger: breakpointForCommunication
## ERROR: ##> debugger: ERROR: Exception : 
nsk.jdi.StepRequest.addClassFilter_rt.filter_rt001$JDITestRuntimeException: 
JDITestRuntimeException : ** EXCEPTION while waiting for event ** : 
nsk.jdi.StepRequest.addClassFilter_rt.filter_rt001$JDITestRuntimeException: 
JDITestRuntimeException : ** TIMEOUT while waiting for event **
## ERROR: ##> debugger: test phase has not finished normally: debuggee is still alive
#--> debugger: ......forcing: vm.exit();
#TEST FAILED

To reproduce bug run script in 
 /net/sqesvr.sfbay/export/vsn/GammaBase/Bugs/4628003 directory:

  sh doit.sh <JAVA_HOME> -client -Xcomp

 where "-client -Xcomp" are optional parameters for debuggee VM mode.
 
======================================================================

Name: dkR10014			Date: 07/22/2002


This bug also affects the following nsk test:
 nsk/jdi/EventRequestManager/createStepRequest/crstepreq004
which will be available since r16 release.

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

###@###.### 2002-10-07

This bug also affects the following nks test:
    nsk/jdi/StepRequest/addClassFilter_rt/filter_rt003
in -Xint and -Xmixed modes.

Comments
Test filter_rt001 sets a jdi StepRequest for each line in a test function with 3 lines. This means that the JVM will be suspended 3 times. Unfortunately the test only resumes the JVM after the first suspend. After the second suspend the JVM will be frozen until the test times out. This happens every time.
30-09-2014

EVALUATION Name: dkR10014 Date: 01/28/2002 I believe that test case is correct, so I re-assign this bug to java/debugger category. ====================================================================== Looks like a problem is in testcase. Wheb debugger requested step the thread "thread1" was not executing method m11 of class TestClass11 instead it was executing method "run" of class Thread1filter_rt001a. Because the debugger had addClassFilter for TestClass10 the step event did not generate. Better way to test this filter is stop the thread1 in method m11 of class TestClass11 by using break point and then make a step request with addClassFilter. Current mechanism does not guarantee that thread will be in filter specified class. Thanks, Swamy ###@###.### 2002-05-17 The problem is in the testcase and in VM. The -Xint mode has a bug which does misses the step event for instruction immediately after monitorenter. In case of -Xcomp mode it is working as expected. Testcase problem is: synchronized(...lockobj) { TestClass10.m11(); } Bytecode instructions for the above java code is: monitorenter invokestatic <...Method m11()> When thread is waiting for lockobj the debugger makes step request with class filter of TestClass10. When debugger resumes the first line of step should be _at_ call to m11(). But the testcase is expecting the step event inside method m11(). That is not correct. If the step event is expected inside the method m11() then synchronized block should be moved inside the method m11 so that we are sure that when thread steps it is inside m11. -Xint mode VM bug is it is not posting the step event before executing the invokestatic method instruction. This problem is known and it seems very difficult fix or almost impossible. Thanks, Swamy
11-06-2004