JDK-8226587 : vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose002/TestDescription.java failed with thread2 is alive
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 11.0.13,13,14,15,16,17,18,19,22
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: windows
  • CPU: x86_64
  • Submitted: 2019-06-21
  • Updated: 2024-03-01
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
tbdUnresolved
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
binder> Waiting for VM initialized
Initial VMStartEvent received: VMStartEvent in thread main
--> debugger: nsk.jdi.VirtualMachine.dispose.dispose002a debuggee launched
debugee.stderr> **> mainThread: debuggee started!
--> debugger: 'ready' recieved

==> nsk/jdi/VirtualMachine/dispose/dispose002        TESTING BEGINS
debugee.stderr> **> mainThread: waiting for an instruction from the debugger ...
debugee.stderr> **> mainThread:        thread2 is created
debugee.stderr> **> mainThread:        synchronized (waitnotifyObj) { enter
debugee.stderr> **> mainThread:        before: test_thread.start()k
debugee.stderr> **> mainThread:        before:   waitnotifyObj.wait();
debugee.stderr> **> thread2: method 'run' enter
debugee.stderr> **> thread2: entered into block:  synchronized (waitnotifyObj)
debugee.stderr> **> thread2: exited from block:  synchronized (waitnotifyObj)
debugee.stderr> **> mainThread:        after:    waitnotifyObj.wait();

==> nsk/jdi/VirtualMachine/dispose/dispose002  new checkready: #0
--> debugger: getting ThreadReference object
--> debugger: setting up breakpoints
--> debugger: setting up a breakpoint: method: 'runt1' line: breakpointLineNumber1
--> debugger:       a breakpoint has been set up
--> debugger:       enabling breakpRequest1
--> debugger:       vm.dispose()
--> debugger:       breakpRequest1 is enabled
--> debugger: ......forcing the main thread to leave synchronized block
--> debugger:       Waiting for thread2 is not alive
debugee.stderr> **> mainThread: mainThread is out of: synchronized (lockingObject)
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: ......sending to the debuggee: 'check_alive'
--> debugger:        expected reply: 'not_alive'
debugee.stderr> **> mainThread: checking on: thread2.isAlive
# ERROR: ##> debugger: ERROR: thread2 is alive
The following stacktrace is for failure analysis.
nsk.share.TestFailure: ##> debugger: ERROR: thread2 is alive
	at nsk.share.Log.logExceptionForFailureAnalysis(Log.java:428)
	at nsk.share.Log.complain(Log.java:399)
	at nsk.jdi.VirtualMachine.dispose.dispose002.log3(dispose002.java:95)
	at nsk.jdi.VirtualMachine.dispose.dispose002.lambda$runThis$0(dispose002.java:285)
	at jdk.test.lib.Utils.waitForCondition(Utils.java:533)
	at nsk.jdi.VirtualMachine.dispose.dispose002.runThis(dispose002.java:278)
	at nsk.jdi.VirtualMachine.dispose.dispose002.run(dispose002.java:81)
	at nsk.jdi.VirtualMachine.dispose.dispose002.main(dispose002.java:76)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
	at PropertyResolvingWrapper.main(PropertyResolvingWrapper.java:104)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:830)
--> debugger: ......sending to the debuggee: 'check_alive'
--> debugger:        expected reply: 'not_alive'
# ERROR: ##> debugger: ERROR: thread2 is alive
debugee.stderr> **> mainThread: checking on: thread2.isAlive
--> debugger: ......sending to the debuggee: 'check_alive'
--> debugger:        expected reply: 'not_alive'
# ERROR: ##> debugger: ERROR: thread2 is alive
debugee.stderr> **> mainThread: checking on: thread2.isAlive
--> debugger: ......sending to the debuggee: 'check_alive'
--> debugger:        expected reply: 'not_alive'
Comments
Here's a log file snippet from the jdk-22+26-2048-tier7 sighting: vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose002/TestDescription.java #section:main ----------messages:(8/1427)---------- command: main nsk.jdi.VirtualMachine.dispose.dispose002 -verbose -arch=linux-aarch64 -waittime=5 -debugee.vmkind=java -transport.address=dynamic -debugee.vmkeys="-XX:MaxRAMPercentage=6.25 -Dtest.boot.jdk=/opt/mach5/mesos/work_dir/jib-master/install/jdk/21/35/bundles/linux-aarch64/jdk-21_linux-aarch64_bin.tar.gz/jdk-21 -Djava.io.tmpdir=/opt/mach5/mesos/work_dir/slaves/0db9c48f-6638-40d0-9a4b-bd9cc7533eb8-S10311/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/96493dbc-ed86-455a-9f82-b08ca85435b6/runs/46141c68-7ead-4b81-85b5-c64b4cf77ae2/testoutput/test-support/jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jdi/tmp -Dcom.oracle.usagetracker.config.file=/opt/mach5/mesos/work_dir/slaves/0db9c48f-6638-40d0-9a4b-bd9cc7533eb8-S10311/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/96493dbc-ed86-455a-9f82-b08ca85435b6/runs/46141c68-7ead-4b81-85b5-c64b4cf77ae2/./testoutput/test-support/jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jdi/usage-tracker.cfg " reason: User specified action: run main/othervm nsk.jdi.VirtualMachine.dispose.dispose002 -verbose -arch=${os.family}-${os.simpleArch} -waittime=5 -debugee.vmkind=java -transport.address=dynamic -debugee.vmkeys="${test.vm.opts} ${test.java.opts}" started: Tue Nov 28 09:31:35 UTC 2023 Mode: othervm [/othervm specified] Timeout information: --- Timeout information end. finished: Tue Nov 28 09:40:54 UTC 2023 elapsed time (seconds): 559.307 ----------configuration:(0/0)---------- ----------System.out:(286/17818)*---------- binder> VirtualMachineManager: version 22.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$2@3b48e4fe binder> Connector arguments: binder> main=nsk.jdi.VirtualMachine.dispose.dispose002a -vbs \u0000-verbose\u0000 \u0000-arch=linux-aarch64\u0000 \u0000-waittime=5\u0000 \u0000-debugee.vmkind=java\u0000 \u0000-transport.address=dynamic\u0000 \u0000-debugee.vmkeys="-XX:MaxRAMPercentage=6.25 -Dtest.boot.jdk=/opt/mach5/mesos/work_dir/jib-master/install/jdk/21/35/bundles/linux-aarch64/jdk-21_linux-aarch64_bin.tar.gz/jdk-21 -Djava.io.tmpdir=/opt/mach5/mesos/work_dir/slaves/0db9c48f-6638-40d0-9a4b-bd9cc7533eb8-S10311/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/96493dbc-ed86-455a-9f82-b08ca85435b6/runs/46141c68-7ead-4b81-85b5-c64b4cf77ae2/testoutput/test-support/jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jdi/tmp -Dcom.oracle.usagetracker.config.file=/opt/mach5/mesos/work_dir/slaves/0db9c48f-6638-40d0-9a4b-bd9cc7533eb8-S10311/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/96493dbc-ed86-455a-9f82-b08ca85435b6/runs/46141c68-7ead-4b81-85b5-c64b4cf77ae2/./testoutput/test-support/jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jdi/usage-tracker.cfg "\u0000 \u0000-pipe.port=43453\u0000 binder> includevirtualthreads=y binder> quote=\u0000 binder> home=/opt/mach5/mesos/work_dir/jib-master/install/jdk-22+26-2048/linux-aarch64-debug.jdk/jdk-22/fastdebug binder> vmexec=java binder> suspend=true binder> options=-XX:MaxRAMPercentage=6.25 -Dtest.boot.jdk=/opt/mach5/mesos/work_dir/jib-master/install/jdk/21/35/bundles/linux-aarch64/jdk-21_linux-aarch64_bin.tar.gz/jdk-21 -Djava.io.tmpdir=/opt/mach5/mesos/work_dir/slaves/0db9c48f-6638-40d0-9a4b-bd9cc7533eb8-S10311/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/96493dbc-ed86-455a-9f82-b08ca85435b6/runs/46141c68-7ead-4b81-85b5-c64b4cf77ae2/testoutput/test-support/jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jdi/tmp -Dcom.oracle.usagetracker.config.file=/opt/mach5/mesos/work_dir/slaves/0db9c48f-6638-40d0-9a4b-bd9cc7533eb8-S10311/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/96493dbc-ed86-455a-9f82-b08ca85435b6/runs/46141c68-7ead-4b81-85b5-c64b4cf77ae2/./testoutput/test-support/jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jdi/usage-tracker.cfg binder> Launching debugee binder> Waiting for VM initialized Initial VMStartEvent received: VMStartEvent in thread main --> debugger: nsk.jdi.VirtualMachine.dispose.dispose002a debuggee launched debugee.stderr> **> mainThread: debuggee started! --> debugger: 'ready' recieved debugee.stderr> **> mainThread: waiting for an instruction from the debugger ... ==> nsk/jdi/VirtualMachine/dispose/dispose002 TESTING BEGINS debugee.stderr> **> mainThread: thread2 is created debugee.stderr> **> mainThread: synchronized (waitnotifyObj) { enter debugee.stderr> **> mainThread: before: test_thread.start() debugee.stderr> **> mainThread: before: waitnotifyObj.wait(); debugee.stderr> **> thread2: method 'run' enter debugee.stderr> **> thread2: entered into block: synchronized (waitnotifyObj) debugee.stderr> **> thread2: exited from block: synchronized (waitnotifyObj) debugee.stderr> **> mainThread: after: waitnotifyObj.wait(); ==> nsk/jdi/VirtualMachine/dispose/dispose002 new checkready: #0 --> debugger: getting ThreadReference object --> debugger: setting up breakpoints --> debugger: setting up a breakpoint: method: 'runt1' line: breakpointLineNumber1 --> debugger: a breakpoint has been set up --> debugger: enabling breakpRequest1 --> debugger: vm.dispose() --> debugger: breakpRequest1 is enabled --> debugger: ......forcing the main thread to leave synchronized block --> debugger: Waiting for thread2 is not alive debugee.stderr> **> mainThread: mainThread is out of: synchronized (lockingObject) 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: ......sending to the debuggee: 'check_alive' --> debugger: expected reply: 'not_alive' debugee.stderr> **> mainThread: checking if thread2 completed debugee.stderr> **> mainThread: thread2 is alive after vm.dispose(). # ERROR: ##> debugger: ERROR: thread2 is alive The following stacktrace is for failure analysis. nsk.share.TestFailure: ##> debugger: ERROR: thread2 is alive at nsk.share.Log.logExceptionForFailureAnalysis(Log.java:431) at nsk.share.Log.complain(Log.java:402) at nsk.jdi.VirtualMachine.dispose.dispose002.log3(dispose002.java:95) at nsk.jdi.VirtualMachine.dispose.dispose002.lambda$runThis$0(dispose002.java:285) at jdk.test.lib.Utils.waitForCondition(Utils.java:606) at nsk.jdi.VirtualMachine.dispose.dispose002.runThis(dispose002.java:278) at nsk.jdi.VirtualMachine.dispose.dispose002.run(dispose002.java:81) at nsk.jdi.VirtualMachine.dispose.dispose002.main(dispose002.java:76) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1570) --> debugger: ......sending to the debuggee: 'check_alive' --> debugger: expected reply: 'not_alive' debugee.stderr> **> mainThread: checking if thread2 completed debugee.stderr> **> mainThread: thread2 is alive after vm.dispose(). # ERROR: ##> debugger: ERROR: thread2 is alive --> debugger: ......sending to the debuggee: 'check_alive' --> debugger: expected reply: 'not_alive' debugee.stderr> **> mainThread: checking if thread2 completed debugee.stderr> **> mainThread: thread2 is alive after vm.dispose(). # ERROR: ##> debugger: ERROR: thread2 is alive <snip> # ERROR: ##> debugger: ERROR: thread2 is alive --> debugger: ......sending to the debuggee: 'check_alive' --> debugger: expected reply: 'not_alive' debugee.stderr> **> mainThread: checking if thread2 completed debugee.stderr> **> mainThread: thread2 is alive after vm.dispose(). # ERROR: ##> debugger: ERROR: thread2 is alive --> debugger: ......sending to the debuggee: 'check_alive' --> debugger: expected reply: 'not_alive' debugee.stderr> **> mainThread: checking if thread2 completed java.io.EOFException at java.base/java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:3217) at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1698) at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:525) at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:483) at nsk.share.jpda.SocketConnection.doReadObject(SocketConnection.java:583) at nsk.share.jpda.SocketConnection.readObject(SocketConnection.java:518) at nsk.share.jpda.SocketIOPipe.readln(SocketIOPipe.java:193) at nsk.jdi.VirtualMachine.dispose.dispose002.lambda$runThis$0(dispose002.java:283) at jdk.test.lib.Utils.waitForCondition(Utils.java:606) at nsk.jdi.VirtualMachine.dispose.dispose002.runThis(dispose002.java:278) at nsk.jdi.VirtualMachine.dispose.dispose002.run(dispose002.java:81) at nsk.jdi.VirtualMachine.dispose.dispose002.main(dispose002.java:76) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1570) #> #> SUMMARY: Following errors occured #> during test execution: #> # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive # ERROR: ##> debugger: ERROR: thread2 is alive ----------System.err:(19/1424)---------- nsk.share.Failure: Caught EOFException while reading an object from PipeIO Listener Thread connection. Check if debuggee process exited prematurely (crashed or killed). at nsk.share.jpda.SocketConnection.readObject(SocketConnection.java:521) at nsk.share.jpda.SocketIOPipe.readln(SocketIOPipe.java:193) at nsk.jdi.VirtualMachine.dispose.dispose002.lambda$runThis$0(dispose002.java:283) at jdk.test.lib.Utils.waitForCondition(Utils.java:606) at nsk.jdi.VirtualMachine.dispose.dispose002.runThis(dispose002.java:278) at nsk.jdi.VirtualMachine.dispose.dispose002.run(dispose002.java:81) at nsk.jdi.VirtualMachine.dispose.dispose002.main(dispose002.java:76) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1570) JavaTest Message: Test threw exception: nsk.share.Failure: Caught EOFException while reading an object from PipeIO Listener Thread connection. Check if debuggee process exited prematurely (crashed or killed). JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: nsk.share.Failure: Caught EOFException while reading an object from PipeIO Listener Thread connection. Check if debuggee process exited prematurely (crashed or killed). ----------rerun:(36/9928)*---------- This bug was previously closed as a duplicate of: JDK-8294881 test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003/TestDescription.java fails but that fix was integrated in jdk-20+24.
28-11-2023

Should be fixed as a part of JDK-8294881
17-11-2022

I've attached the logs from my sighting in my jdk-20+10 linux-x64 stress testing: $ unzip -l jdk-20+10_linux.8226587.zip Archive: jdk-20+10_linux.8226587.zip Length Date Time Name --------- ---------- ----- ---- 103553 2022-08-13 12:46 jdk-20+10_3/failures.linux-x86_64/TestDescription.jtr.slowdebug --------- ------- 103553 1 file
21-08-2022

I've attached the logs from my sighting in my jdk-20+11 linux-x64 stress testing: $ unzip -l jdk-20+11_linux.8226587.zip Archive: jdk-20+11_linux.8226587.zip Length Date Time Name --------- ---------- ----- ---- 103532 2022-08-18 14:49 jdk-20+11_1/failures.linux-x86_64/TestDescription.jtr.slowdebug --------- ------- 103532 1 file
21-08-2022

I've attached the logs from my sighting in my jdk-20+9 linux0x64 stress testing: $ unzip -l jdk-20+9_linux.8226587.zip Archive: jdk-20+9_linux.8226587.zip Length Date Time Name --------- ---------- ----- ---- 103013 2022-08-06 13:16 jdk-20+9_3/failures.linux-x86_64/TestDescription.jtr.slowdebug --------- ------- 103013 1 file
07-08-2022

With loom the failure is a bit different because the debuggee attempts to call Thread.resume() if the thread is still alive, and this generates and UnsupportedOperationException because you can't call Thread.resume() on a virtual thread. debugee.stderr> java.lang.reflect.InvocationTargetException debugee.stderr> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119) debugee.stderr> at java.base/java.lang.reflect.Method.invoke(Method.java:577) debugee.stderr> at nsk.share.MainWrapper.lambda$main$0(MainWrapper.java:55) debugee.stderr> at java.base/java.lang.VirtualThread.run(VirtualThread.java:293) debugee.stderr> at java.base/java.lang.VirtualThread$VThreadContinuation.lambda$new$0(VirtualThread.java:178) debugee.stderr> at java.base/jdk.internal.vm.Continuation.enter0(Continuation.java:343) debugee.stderr> at java.base/jdk.internal.vm.Continuation.enter(Continuation.java:336) debugee.stderr> Caused by: java.lang.UnsupportedOperationException debugee.stderr> at java.base/java.lang.Thread.resume(Thread.java:1857) debugee.stderr> at nsk.jdi.VirtualMachine.dispose.dispose003a.main(dispose003a.java:139) debugee.stderr> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) debugee.stderr> ... 6 more debugee.stderr> Exception in thread "old-m-a-i-n" java.lang.UnsupportedOperationException debugee.stderr> at java.base/java.lang.Thread.resume(Thread.java:1857) debugee.stderr> at nsk.jdi.VirtualMachine.dispose.dispose003a.main(dispose003a.java:139) debugee.stderr> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) debugee.stderr> at java.base/java.lang.reflect.Method.invoke(Method.java:577) debugee.stderr> at nsk.share.MainWrapper.lambda$main$0(MainWrapper.java:55) debugee.stderr> at java.base/java.lang.VirtualThread.run(VirtualThread.java:293) debugee.stderr> at java.base/java.lang.VirtualThread$VThreadContinuation.lambda$new$0(VirtualThread.java:178) debugee.stderr> at java.base/jdk.internal.vm.Continuation.enter0(Continuation.java:343) debugee.stderr> at java.base/jdk.internal.vm.Continuation.enter(Continuation.java:336) ----------System.err:(18/1321)---------- java.lang.NullPointerException: Cannot invoke "String.equals(Object)" because "<local1>" is null at nsk.jdi.VirtualMachine.dispose.dispose003.lambda$runThis$0(dispose003.java:249) at jdk.test.lib.Utils.waitForCondition(Utils.java:590) at nsk.jdi.VirtualMachine.dispose.dispose003.runThis(dispose003.java:243) at nsk.jdi.VirtualMachine.dispose.dispose003.run(dispose003.java:77) at nsk.jdi.VirtualMachine.dispose.dispose003.main(dispose003.java:72) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:577) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:142) at java.base/java.lang.VirtualThread.run(VirtualThread.java:293) at java.base/java.lang.VirtualThread$VThreadContinuation.lambda$new$0(VirtualThread.java:178) at java.base/jdk.internal.vm.Continuation.enter0(Continuation.java:343) at java.base/jdk.internal.vm.Continuation.enter(Continuation.java:336)
25-03-2022

[Note: the conclusion found in this comment is not fully accurate. The root issue is that the test assumes that immediately after calling vm.dispose() that the test thread on the debuggee side will have exited, and when it queries the debuggee using a side channel, the debuggee will confirm it has exited. The problem is that once vm.dispose() is returns, you need to give the test thread a chance to resume and exit, and the test does not do this, so the query responds that the thread is still alive. A short delay after the vm.dispose() should fix this issue.] The last log message on thread2 is: debugee.stderr> **> thread2: method 'runt1': enter This log message comes from this code: log("call to the method 'runt1'"); runt1(); run1() looks like: public void runt1() { int i0 = 0; log("method 'runt1': enter"); i0 = 1; log("method 'runt1': body: i0 == " + i0); log("method 'runt1': exit"); return; } Before all this, a breakpoint is setup on line 3 of runt1(), so I assume this breakpoint is being hit, and then we never continue from there. However, it looks like this breakpoint should never be hit. The comment at the start of the test says: * The test checks up that after call to VirtualMachine.dispose(),<BR> * a breakpoint event request set up before the call, <BR> * is cancelled. <BR> It looks like vm.dispose() is not properly cancelling the breakpoint before returning. I looked at the JDWP side of things, for which there is the VirtualMachine.Dispose command. The JDWP spec basically says the same thing as the javadoc for JDI VirtualMachine.dispose(), which isn’t surprising: https://docs.oracle.com/javase/10/docs/specs/jdwp/jdwp-protocol.html#JDWP_VirtualMachine_Dispose And although the jdwp agent dispose() function does nothing: static jboolean dispose(PacketInputStream *in, PacketOutputStream *out) { return JNI_TRUE; } ...there is logic in the debugLoop_run() code to exit the loop that processes incoming JDWP commands and teardown the connection after the Dispose command is received. There's also code in VirtualMachine.dispose() to teardown the connection after sending the Dispose command, so disconnecting could end up being initiated by either side depending on the timing. I don't think that is an issue, but what is an issue is that when VirtualMachine.dispose() returns, there is no guarantee that the jdwp agent has completed the "reset", only that the connection has been terminated. The "reset" happens after termination of the connection when debugLoop_run() calls debugInit_reset(). Probably the best way to fix this would be in the JDWP spec by having the VirtualMachine.Dispose command include a reply packet, so the JDI VirtualMachine.dispose() can know that after it has sent the VirtualMachine.Dispose command and received a reply, the debug agent has been reset and breakpoint events have been cleared. As things stand now, there is no way to acknowledge that VirtualMachine.Dispose has done anything, only that it has been received. However, a spec change in this manner is not really backwards compatible, and would not fix any existing JDI clients unless they adapted to the spec change. One workaround in VirtualMachine.dispose() might be for it to send some other JDWP command after sending the VirtualMachine.Dispose and before tearing down the connection. This second command sent should result in some sort of IOException, because the debug agent will have torn down the connection before reading the command. Once that IOException is received, VirtualMachine.dispose() is done and should be able to safely return knowing that the debug agent won't send it any more events. On the jdwp agent side, we would set some sort of flag after receiving the VirtualMachine.Dispose and before tearing down the connection. This flag would prevent processing of any event requests (ie breakpoints would be ignored). Doing it this way would guarantee that the connection is not torn down until the flag is set, and that no events will be processed once the connection is torn down.
25-03-2022

This also impacts vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003/TestDescription.java. It probably can happen with all the VirtualMachine/dispose tests. The tests assume that as soon a VirtualMachine.dispose() returns, a test thread on the debuggee side has been resumed and exited. In the case of both dispose002 and dispose003, the debugger side uses a side channel to ask the debuggee if the test thread has been resumed. The debuggee checks by calling Thread.isAlive() because it assumes that if the thread was resumed it would have exited. But there is no guarantee that it will have exited fast enough since this is done asysc w.r.t. the VirtualMachine.dipose(). A short delay in on the debugger side of the test after calling VirtualMachine.dispose() of the test would probably resolve this issue.
25-03-2022

Here's a log file snippet from the jdk-19+15-902-tier5 sighting: vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose002/TestDescription.java ==> nsk/jdi/VirtualMachine/dispose/dispose002 new checkready: #0 --> debugger: getting ThreadReference object --> debugger: setting up breakpoints --> debugger: setting up a breakpoint: method: 'runt1' line: breakpointLineNumber1 --> debugger: a breakpoint has been set up --> debugger: enabling breakpRequest1 --> debugger: vm.dispose() --> debugger: breakpRequest1 is enabled --> debugger: ......forcing the main thread to leave synchronized block debugee.stderr> **> mainThread: mainThread is out of: synchronized (lockingObject) 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: Waiting for thread2 is not alive --> debugger: ......sending to the debuggee: 'check_alive' --> debugger: expected reply: 'not_alive' debugee.stderr> **> mainThread: checking on: thread2.isAlive # ERROR: ##> debugger: ERROR: thread2 is alive The following stacktrace is for failure analysis. nsk.share.TestFailure: ##> debugger: ERROR: thread2 is alive at nsk.share.Log.logExceptionForFailureAnalysis(Log.java:432) at nsk.share.Log.complain(Log.java:403) at nsk.jdi.VirtualMachine.dispose.dispose002.log3(dispose002.java:95) at nsk.jdi.VirtualMachine.dispose.dispose002.lambda$runThis$0(dispose002.java:285) at jdk.test.lib.Utils.waitForCondition(Utils.java:588) at nsk.jdi.VirtualMachine.dispose.dispose002.runThis(dispose002.java:278) at nsk.jdi.VirtualMachine.dispose.dispose002.run(dispose002.java:81) at nsk.jdi.VirtualMachine.dispose.dispose002.main(dispose002.java:76) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:577) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:828) --> debugger: ......sending to the debuggee: 'check_alive' --> debugger: expected reply: 'not_alive' debugee.stderr> **> mainThread: checking on: thread2.isAlive # ERROR: ##> debugger: ERROR: thread2 is alive --> debugger: ......sending to the debuggee: 'check_alive' --> debugger: expected reply: 'not_alive' debugee.stderr> **> mainThread: checking on: thread2.isAlive <snip pages of the same output> # ERROR: ##> debugger: ERROR: thread2 is alive debugee.stderr> **> mainThread: checking on: thread2.isAlive --> debugger: ......sending to the debuggee: 'check_alive' --> debugger: expected reply: 'not_alive' java.net.SocketException: Connection reset at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:320) at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:347) at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:800) at java.base/java.net.Socket$SocketInputStream.read(Socket.java:966) at java.base/java.net.Socket$SocketInputStream.read(Socket.java:961) at java.base/java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2895) at java.base/java.io.ObjectInputStream$BlockDataInputStream.peek(ObjectInputStream.java:3222) at java.base/java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:3232) at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1706) at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:538) at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:496) at nsk.share.jpda.SocketConnection.doReadObject(SocketConnection.java:581) at nsk.share.jpda.SocketConnection.readObject(SocketConnection.java:518) at nsk.share.jpda.SocketIOPipe.readln(SocketIOPipe.java:190) at nsk.jdi.VirtualMachine.dispose.dispose002.lambda$runThis$0(dispose002.java:283) at jdk.test.lib.Utils.waitForCondition(Utils.java:588) at nsk.jdi.VirtualMachine.dispose.dispose002.runThis(dispose002.java:278) at nsk.jdi.VirtualMachine.dispose.dispose002.run(dispose002.java:81) at nsk.jdi.VirtualMachine.dispose.dispose002.main(dispose002.java:76) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:577) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:828) <snip> ----------System.err:(19/1345)---------- nsk.share.Failure: Caught Exception while reading an object from PipeIO Listener Thread connection: java.net.SocketException: Connection reset at nsk.share.jpda.SocketConnection.readObject(SocketConnection.java:523) at nsk.share.jpda.SocketIOPipe.readln(SocketIOPipe.java:190) at nsk.jdi.VirtualMachine.dispose.dispose002.lambda$runThis$0(dispose002.java:283) at jdk.test.lib.Utils.waitForCondition(Utils.java:588) at nsk.jdi.VirtualMachine.dispose.dispose002.runThis(dispose002.java:278) at nsk.jdi.VirtualMachine.dispose.dispose002.run(dispose002.java:81) at nsk.jdi.VirtualMachine.dispose.dispose002.main(dispose002.java:76) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:577) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:828) JavaTest Message: Test threw exception: nsk.share.Failure: Caught Exception while reading an object from PipeIO Listener Thread connection: java.net.SocketException: Connection reset JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: nsk.share.Failure: Caught Exception while reading an object from PipeIO Listener Thread connection: java.net.SocketException: Connection reset ----------rerun:(33/8380)*----------
20-03-2022