JDK-4628004 : JDI testcase issuspended002 failing witn -Xcomp
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 1.4.0,1.4.2
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2002-01-24
  • Updated: 2014-01-08
  • Resolved: 2012-02-13
Related Reports
Relates :  
Relates :  
Relates :  
Description
Testcase :
nsk/jdi/ThreadReference/isSuspended/issuspended002

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.ThreadReference.isSuspended.issuspended002 -arch=sparc -waittime=2 -debugee.vmkind=java "-debugee.vmkeys=-client -client -Xcomp"
##Exit status of execution step=97
##!checkExitCode

## ERROR: ##> debugger: ERROR:  timeout for waiting for a BreakpintEvent
## ERROR: TEST FAILED



Name: dkR10014			Date: 01/29/2002



The test fails only when debuggee class (issuspended002a 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, Windows NT 4.0.

The test checks that results of the method
 com.sun.jdi.ThreadReference.isSuspended()
complies with its spec.

The test checks a case when new thread (thread2) beside main one is created
in debuggee and if thread2.isSuspended() is correct for various suspend
count.
 
Please see detailed description of test case algorithm in header comment
of issuspended002.java file. 

The test fails because the expected Breakpoint event is not received in
debugger. This event should be reported for Breakpoint request been set up
for line in method exclusively invoked in thread2 after resuming.

Below is part of test log demonstrating the failure:

--> debugger:       double resuming thread2 with thread2.resume();
--> debugger:          thread2.suspendCount() == 1
--> debugger:      :   thread2.isSuspended()
--> debugger:      enabling breakpRequest1
--> debugger:          thread2.suspendCount() == 0
--> debugger:      :  !thread2.isAtBreakpoint() before call to breakpoint()
--> debugger:        waiting for BreakpointEvent
--> debugger:        new:  eventSet = eventQueue.remove();
--> debugger:      :  eventSet != null;  size == 1
--> debugger:       VMStartEvent removed
--> debugger:        new:  eventSet = eventQueue.remove();
# ERROR: ##> debugger: ERROR:  timeout for waiting for a BreakpintEvent
--> debugger:       resuming both second and main thread
debugee.stderr> **> thread2: entered into block:  synchronized (lockingObject)
debugee.stderr> **> thread2: exited from block:  synchronized (lockingObject)
debugee.stderr> **> thread2: call to the method 'runt1'
debugee.stderr> **> thread2: method 'runt1' enter
--> debugger:      the end of testing


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

  sh doit.sh <JAVA_HOME> -client -Xcomp

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

Comments
EVALUATION Sounds like a testcase issue. None the less, it can be closed as a duplicate of 4903717.
13-02-2012

EVALUATION Name: dkR10014 Date: 01/29/2002 I believe that test case is correct, so I re-assign this bug to java/debugger category. ====================================================================== ###@###.### 2002-04-10 Could not reproduce this bug with the latest weekahead binary. Closing it for now, and may be reopened if the same error is seen.
10-04-2002