-
Bug
-
Resolution: Cannot Reproduce
-
P4
-
14
-
x86_64
-
windows
The following test failed in the JDK14 CI:
vmTestbase/nsk/jdi/BScenarios/singlethrd/tc01x002/TestDescription.java
Here's a snippet from the log file:
#section:main
----------messages:(6/628)----------
command: main PropertyResolvingWrapper nsk.jdi.BScenarios.singlethrd.tc01x002 -verbose -arch=${os.family}-${os.simpleArch} -waittime=5 -debugee.vmkind=java -transport.address=dynamic "-debugee.vmkeys=${test.vm.opts} ${test.java.opts}"
reason: User specified action: run main/othervm PropertyResolvingWrapper nsk.jdi.BScenarios.singlethrd.tc01x002 -verbose -arch=${os.family}-${os.simpleArch} -waittime=5 -debugee.vmkind=java -transport.address=dynamic "-debugee.vmkeys=${test.vm.opts} ${test.java.opts}"
Mode: othervm [/othervm specified]
Timeout information:
--- Timeout information end.
elapsed time (seconds): 514.896
----------configuration:(0/0)----------
----------System.out:(62/2673)*----------
run [nsk.jdi.BScenarios.singlethrd.tc01x002, -verbose, -arch=windows-x64, -waittime=5, -debugee.vmkind=java, -transport.address=dynamic, -debugee.vmkeys=-XX:MaxRAMPercentage=3 -Xshare:off -showversion]
binder> VirtualMachineManager: version 14.0
binder> Finding connector: default
binder> LaunchingConnector:
binder> name: com.sun.jdi.CommandLineLaunch
binder> description: Launches target using Sun Java VM command line and attaches to it
binder> transport: com.sun.tools.jdi.SunCommandLineLauncher$1@5ec6c5c8
binder> Connector arguments:
binder> home=c:\\ade\\mesos\\work_dir\\jib-master\\install\\jdk-14+26-1241\\windows-x64-debug.jdk\\jdk-14\\fastdebug
binder> vmexec=java
binder> options=-XX:MaxRAMPercentage=3 -Xshare:off -showversion
binder> main=nsk.jdi.BScenarios.singlethrd.tc01x002a "-verbose" "-arch=windows-x64" "-waittime=5" "-debugee.vmkind=java" "-transport.address=dynamic" "-debugee.vmkeys=-XX:MaxRAMPercentage=3 -Xshare:off -showversion" "-pipe.port=27148"
binder> quote="
binder> suspend=true
binder> Launching debugee
binder> Waiting for VM initialized
Initial VMStartEvent received: VMStartEvent in thread main
debugee.stderr> java version "14-ea" 2020-03-17
debugee.stderr> Java(TM) SE Runtime Environment (fastdebug build 14-ea+26-1241)
debugee.stderr> Java HotSpot(TM) 64-Bit Server VM (fastdebug build 14-ea+26-1241, mixed mode)
binder> Received expected signal from debugee: ready
TEST BEGINS
===========
Tested class :nsk.jdi.BScenarios.singlethrd.tc01x002a
binder> Breakpoint set:
breakpoint request nsk.jdi.BScenarios.singlethrd.tc01x002a:69 (disabled)
debugee.stderr> performTest::line 0
event ===>>> BreakpointEvent@nsk.jdi.BScenarios.singlethrd.tc01x002a:69 in thread main
BreakpointEvent arrived. Location - 69 line
debugee.stderr> performTest::breakpoint line
event ===>>> StepEvent@nsk.jdi.BScenarios.singlethrd.tc01x002a:70 in thread main
event info:
thread - main
source - tc01x002a.java
method - performTest
line - 70
debugee.stderr> performTest::creating tc01x002aClass1 object
event ===>>> StepEvent@nsk.jdi.BScenarios.singlethrd.tc01x002a:71 in thread main
event info:
thread - main
source - tc01x002a.java
method - performTest
line - 71
event ===>>> StepEvent@nsk.jdi.BScenarios.singlethrd.tc01x002aClass1:76 in thread main
event info:
thread - main
source - tc01x002a.java
method - <init>
line - 76
StepEvent steps to the expected line 76
=============
TEST FINISHES
debugee.stderr> tc01x002aClass1::constructor is called
debugee.stderr> quit
debugee.stderr> completed succesfully.
Timeout refired 480 times
----------System.err:(3/177)----------
java version "14-ea" 2020-03-17
Java(TM) SE Runtime Environment (fastdebug build 14-ea+26-1241)
Java HotSpot(TM) 64-Bit Server VM (fastdebug build 14-ea+26-1241, mixed mode)
----------rerun:(38/5799)*----------
So the test timed out at 480 seconds/8 minutes. While JTREG
was doing the timeout handler, it appears that the test passed.
See the "TEST FINISHES" at the end of the log file.
> elapsed time (seconds): 514.896
shows that perhaps the test needs a little longer to run.
Perhaps changing the default timeout value from
120 seconds/2 minutes to 180 seconds/3 minutes
would give the test time to finish on slower hosts.
With the default timeout factor (4X) that would give
the test 720 seconds/12 minutes instead of
480 seconds/8 minutes.
I filed a very similar bug for a JDI test in another area:
JDK-8234594 JDI BScenarios/hotswap/tc05x002 failed due to timeout
vmTestbase/nsk/jdi/BScenarios/singlethrd/tc01x002/TestDescription.java
Here's a snippet from the log file:
#section:main
----------messages:(6/628)----------
command: main PropertyResolvingWrapper nsk.jdi.BScenarios.singlethrd.tc01x002 -verbose -arch=${os.family}-${os.simpleArch} -waittime=5 -debugee.vmkind=java -transport.address=dynamic "-debugee.vmkeys=${test.vm.opts} ${test.java.opts}"
reason: User specified action: run main/othervm PropertyResolvingWrapper nsk.jdi.BScenarios.singlethrd.tc01x002 -verbose -arch=${os.family}-${os.simpleArch} -waittime=5 -debugee.vmkind=java -transport.address=dynamic "-debugee.vmkeys=${test.vm.opts} ${test.java.opts}"
Mode: othervm [/othervm specified]
Timeout information:
--- Timeout information end.
elapsed time (seconds): 514.896
----------configuration:(0/0)----------
----------System.out:(62/2673)*----------
run [nsk.jdi.BScenarios.singlethrd.tc01x002, -verbose, -arch=windows-x64, -waittime=5, -debugee.vmkind=java, -transport.address=dynamic, -debugee.vmkeys=-XX:MaxRAMPercentage=3 -Xshare:off -showversion]
binder> VirtualMachineManager: version 14.0
binder> Finding connector: default
binder> LaunchingConnector:
binder> name: com.sun.jdi.CommandLineLaunch
binder> description: Launches target using Sun Java VM command line and attaches to it
binder> transport: com.sun.tools.jdi.SunCommandLineLauncher$1@5ec6c5c8
binder> Connector arguments:
binder> home=c:\\ade\\mesos\\work_dir\\jib-master\\install\\jdk-14+26-1241\\windows-x64-debug.jdk\\jdk-14\\fastdebug
binder> vmexec=java
binder> options=-XX:MaxRAMPercentage=3 -Xshare:off -showversion
binder> main=nsk.jdi.BScenarios.singlethrd.tc01x002a "-verbose" "-arch=windows-x64" "-waittime=5" "-debugee.vmkind=java" "-transport.address=dynamic" "-debugee.vmkeys=-XX:MaxRAMPercentage=3 -Xshare:off -showversion" "-pipe.port=27148"
binder> quote="
binder> suspend=true
binder> Launching debugee
binder> Waiting for VM initialized
Initial VMStartEvent received: VMStartEvent in thread main
debugee.stderr> java version "14-ea" 2020-03-17
debugee.stderr> Java(TM) SE Runtime Environment (fastdebug build 14-ea+26-1241)
debugee.stderr> Java HotSpot(TM) 64-Bit Server VM (fastdebug build 14-ea+26-1241, mixed mode)
binder> Received expected signal from debugee: ready
TEST BEGINS
===========
Tested class :nsk.jdi.BScenarios.singlethrd.tc01x002a
binder> Breakpoint set:
breakpoint request nsk.jdi.BScenarios.singlethrd.tc01x002a:69 (disabled)
debugee.stderr> performTest::line 0
event ===>>> BreakpointEvent@nsk.jdi.BScenarios.singlethrd.tc01x002a:69 in thread main
BreakpointEvent arrived. Location - 69 line
debugee.stderr> performTest::breakpoint line
event ===>>> StepEvent@nsk.jdi.BScenarios.singlethrd.tc01x002a:70 in thread main
event info:
thread - main
source - tc01x002a.java
method - performTest
line - 70
debugee.stderr> performTest::creating tc01x002aClass1 object
event ===>>> StepEvent@nsk.jdi.BScenarios.singlethrd.tc01x002a:71 in thread main
event info:
thread - main
source - tc01x002a.java
method - performTest
line - 71
event ===>>> StepEvent@nsk.jdi.BScenarios.singlethrd.tc01x002aClass1:76 in thread main
event info:
thread - main
source - tc01x002a.java
method - <init>
line - 76
StepEvent steps to the expected line 76
=============
TEST FINISHES
debugee.stderr> tc01x002aClass1::constructor is called
debugee.stderr> quit
debugee.stderr> completed succesfully.
Timeout refired 480 times
----------System.err:(3/177)----------
java version "14-ea" 2020-03-17
Java(TM) SE Runtime Environment (fastdebug build 14-ea+26-1241)
Java HotSpot(TM) 64-Bit Server VM (fastdebug build 14-ea+26-1241, mixed mode)
----------rerun:(38/5799)*----------
So the test timed out at 480 seconds/8 minutes. While JTREG
was doing the timeout handler, it appears that the test passed.
See the "TEST FINISHES" at the end of the log file.
> elapsed time (seconds): 514.896
shows that perhaps the test needs a little longer to run.
Perhaps changing the default timeout value from
120 seconds/2 minutes to 180 seconds/3 minutes
would give the test time to finish on slower hosts.
With the default timeout factor (4X) that would give
the test 720 seconds/12 minutes instead of
480 seconds/8 minutes.
I filed a very similar bug for a JDI test in another area:
- relates to
-
JDK-8234594 JDI BScenarios/hotswap/tc05x002 failed due to timeout
-
- Closed
-
-
JDK-8292945 [LOOM] JDI ClassType/invokeMethod/invokemethod008 test failed with "!!!out of wait time!!!"
-
- Closed
-