P4
com/sun/jdi/ResumeOneThreadTest.java is timing out, but only on Windows and only when using the virtual thread wrapper for the main debuggee thread. The two threads that the debuggee creates are not virtual.
The debuggee side of the test creates two threads and has them run until they hit breakpoints setup by the debugger. Although the debuggee is a virtual thread, the two threads it creates are not. The log shows no output for the debuggee, but clearly it has made some progress (and even done a println) based on the thread dump that occurs when the process times out. It includes the following for the 2 threads that the debuggeee creates:
"Thread 1" #28 [13616] daemon prio=5 os_prio=0 cpu=0.00ms elapsed=1936.84s allocated=64B defined_classes=0 tid=0x0000017cf9412e60 nid=13616 at breakpoint [0x00000023d4bff000]
java.lang.Thread.State: RUNNABLE
Thread: 0x0000017cf9412e60 [0x3530] State: _at_safepoint _at_poll_safepoint 0
JavaThread state: _thread_blocked
at ResumeOneThreadTarg.bkpt1(ResumeOneThreadTest.java:67)
at ResumeOneThreadTarg.run1(ResumeOneThreadTest.java:71)
at ResumeOneThreadTarg.run(ResumeOneThreadTest.java:60)
"Thread 2" #29 [43124] daemon prio=5 os_prio=0 cpu=0.00ms elapsed=1936.84s allocated=0B defined_classes=0 tid=0x0000017cf9415470 nid=43124 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
Thread: 0x0000017cf9415470 [0xa874] State: _at_safepoint _at_poll_safepoint 0
JavaThread state: _thread_blocked
So the first thread has reached the breakpoint and the second one has not started yet. Note the debuggee main thread does the following before even trying to create these two threads:
System.out.println(" Debuggee: Howdy!");
Yet we don't see this in the output.
The really odd thing is that the debuggee main thread no longer appears in the thread dump. Since the vthread wrapper was used for it, we should see both the old-m-a-i-n platform thread, and a carrier thread that the vthread wrapper runs on. Yet neither are present. It is especially odd that there are no carrier threads. One had to have been created in order to support the wrapper, and should not have exited, yet it appears to have.
The debuggee side of the test creates two threads and has them run until they hit breakpoints setup by the debugger. Although the debuggee is a virtual thread, the two threads it creates are not. The log shows no output for the debuggee, but clearly it has made some progress (and even done a println) based on the thread dump that occurs when the process times out. It includes the following for the 2 threads that the debuggeee creates:
"Thread 1" #28 [13616] daemon prio=5 os_prio=0 cpu=0.00ms elapsed=1936.84s allocated=64B defined_classes=0 tid=0x0000017cf9412e60 nid=13616 at breakpoint [0x00000023d4bff000]
java.lang.Thread.State: RUNNABLE
Thread: 0x0000017cf9412e60 [0x3530] State: _at_safepoint _at_poll_safepoint 0
JavaThread state: _thread_blocked
at ResumeOneThreadTarg.bkpt1(ResumeOneThreadTest.java:67)
at ResumeOneThreadTarg.run1(ResumeOneThreadTest.java:71)
at ResumeOneThreadTarg.run(ResumeOneThreadTest.java:60)
"Thread 2" #29 [43124] daemon prio=5 os_prio=0 cpu=0.00ms elapsed=1936.84s allocated=0B defined_classes=0 tid=0x0000017cf9415470 nid=43124 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
Thread: 0x0000017cf9415470 [0xa874] State: _at_safepoint _at_poll_safepoint 0
JavaThread state: _thread_blocked
So the first thread has reached the breakpoint and the second one has not started yet. Note the debuggee main thread does the following before even trying to create these two threads:
System.out.println(" Debuggee: Howdy!");
Yet we don't see this in the output.
The really odd thing is that the debuggee main thread no longer appears in the thread dump. Since the vthread wrapper was used for it, we should see both the old-m-a-i-n platform thread, and a carrier thread that the vthread wrapper runs on. Yet neither are present. It is especially odd that there are no carrier threads. One had to have been created in order to support the wrapper, and should not have exited, yet it appears to have.