RFR: JDK-8211013: TESTBUG] nsk/jdb/kill/kill002 wait for message and prompt

[Gary Adams]

kill ... killing ... killed <prompt>

This bug was filed to cover the issue with the kill002 test,
which sometimes did not consume enough of the reply
messages after the wait for the "killed" message is observed.

When a "kill" command is issued it is processed as an asynchronous
command. The "killing" message is presented before the action is
evaluated, and the "killed" message is presented after the evaluation
returns. When the asynchronous action is completed a prompt is
displayed after restoring the current thread info when the action
was requested.

Issue: https://bugs.openjdk.java.net/browse/JDK-8211013

Proposed fix:

diff --git
a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
--- a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
+++ b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
@@ -488,6 +488,7 @@
showPrompt = false;
evaluator.commandNext();
} else if (cmd.equals("kill")) {
+ showPrompt = false; // asynchronous
command
evaluator.commandKill(t);
} else if (cmd.equals("interrupt")) {
evaluator.commandInterrupt(t);

Sample output:
...
main[1] threads
Group system:
(java.lang.ref.Reference$ReferenceHandler)0x172 Reference Handler running
(java.lang.ref.Finalizer$FinalizerThread)0x173 Finalizer
cond. waiting
(java.lang.Thread)0x174 Signal Dispatcher running
Group main:
(java.lang.Thread)0x1 main
running (at breakpoint)
(nsk.jdb.kill.kill002.MyThread)0x2c9 Thread-0
cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e2 Thread-1
cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e3 Thread-2
cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e4 Thread-3
cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e5 Thread-4
cond. waiting
Group InnocuousThreadGroup:
(jdk.internal.misc.InnocuousThread)0x19a Common-Cleaner
cond. waiting
main[1] kill 0x2c9 nsk.jdb.kill.kill002.kill002a.exceptions[0]
killing thread: Thread-0
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-0', id=713) killed
main[1] kill 0x2e2 nsk.jdb.kill.kill002.kill002a.exceptions[1]
killing thread: Thread-1
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-1', id=738) killed
main[1] kill 0x2e3 nsk.jdb.kill.kill002.kill002a.exceptions[2]
killing thread: Thread-2
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-2', id=739) killed
main[1] kill 0x2e4 nsk.jdb.kill.kill002.kill002a.exceptions[3]
killing thread: Thread-3
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-3', id=740) killed
main[1] kill 0x2e5 nsk.jdb.kill.kill002.kill002a.exceptions[4]
killing thread: Thread-4
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-4', id=741) killed
main[1] threads
...

An alternate proposal would include the simple prompt. e.g.
...
main[1] kill 0x2c9 nsk.jdb.kill.kill002.kill002a.exceptions[0]

killing thread: Thread-0

instance of nsk.jdb.kill.kill002.MyThread(name='Thread-0', id=713) killed
main[1] kill 0x2e2 nsk.jdb.kill.kill002.kill002a.exceptions[1]

killing thread: Thread-1

Test in progress.

[Chris Plummer]

Hi Gary,

I think the simple prompt is meant to indicate that execution is
suspended, but there is no current thread. I don't think that is the
case here, so probably best not to use your alternate suggestion of a
simple prompt. There doesn't seem to be much purpose in the first prompt
being printed. You also seem to just be handling the situation the same
as we do for other async commands, so looks good to me.

thanks,

Chris

Post by Gary Adams
kill ... killing ... killed <prompt>
This bug was filed to cover the issue with the kill002 test,
which sometimes did not consume enough of the reply
messages after the wait for the "killed" message is observed.
When a "kill" command is issued it is processed as an asynchronous
command. The "killing" message is presented before the action is
evaluated, and the "killed" message is presented after the evaluation
returns. When the asynchronous action is completed a prompt is
displayed after restoring the current thread info when the action
was requested.
  Issue: https://bugs.openjdk.java.net/browse/JDK-8211013
diff --git
a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
--- a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
+++ b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
@@ -488,6 +488,7 @@
                             showPrompt = false;
                             evaluator.commandNext();
                         } else if (cmd.equals("kill")) {
+                            showPrompt = false;        //
asynchronous command
                             evaluator.commandKill(t);
                         } else if (cmd.equals("interrupt")) {
                             evaluator.commandInterrupt(t);
...
main[1] threads
  (java.lang.ref.Reference$ReferenceHandler)0x172 Reference Handler
running
  (java.lang.ref.Finalizer$FinalizerThread)0x173 Finalizer        
cond. waiting
  (java.lang.Thread)0x174                         Signal Dispatcher
running
  (java.lang.Thread)0x1 main              running (at breakpoint)
  (nsk.jdb.kill.kill002.MyThread)0x2c9 Thread-0          cond. waiting
  (nsk.jdb.kill.kill002.MyThread)0x2e2 Thread-1          cond. waiting
  (nsk.jdb.kill.kill002.MyThread)0x2e3 Thread-2          cond. waiting
  (nsk.jdb.kill.kill002.MyThread)0x2e4 Thread-3          cond. waiting
  (nsk.jdb.kill.kill002.MyThread)0x2e5 Thread-4          cond. waiting
  (jdk.internal.misc.InnocuousThread)0x19a Common-Cleaner    cond.
waiting
main[1] kill 0x2c9 nsk.jdb.kill.kill002.kill002a.exceptions[0]
killing thread: Thread-0
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-0', id=713) killed
main[1] kill 0x2e2 nsk.jdb.kill.kill002.kill002a.exceptions[1]
killing thread: Thread-1
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-1', id=738) killed
main[1] kill 0x2e3 nsk.jdb.kill.kill002.kill002a.exceptions[2]
killing thread: Thread-2
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-2', id=739) killed
main[1] kill 0x2e4 nsk.jdb.kill.kill002.kill002a.exceptions[3]
killing thread: Thread-3
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-3', id=740) killed
main[1] kill 0x2e5 nsk.jdb.kill.kill002.kill002a.exceptions[4]
killing thread: Thread-4
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-4', id=741) killed
main[1] threads
...
An alternate proposal would include the simple prompt. e.g.
...
main[1] kill 0x2c9 nsk.jdb.kill.kill002.kill002a.exceptions[0]

Post by Gary Adams
killing thread: Thread-0

instance of nsk.jdb.kill.kill002.MyThread(name='Thread-0', id=713) killed
main[1] kill 0x2e2 nsk.jdb.kill.kill002.kill002a.exceptions[1]

Post by Gary Adams
killing thread: Thread-1

[Gary Adams]

Still seeing a 1/1000 kill002 failure on solais-sparcv9-debug.

The message waiting for "killing" is working correctly
and only one compound prompt is being delivered.

After all the killing a final cont is issued to proceed to the last
breakpoint.
The simple prompt is seen in the pending reply along with exceptions.
Need to understand why it was not a clean kill.


...
Sending command: kill 0x2ee nsk.jdb.kill.kill002.kill002a.exceptions[4]
reply[0]: killing thread: Thread-4
reply[1]: instance of nsk.jdb.kill.kill002.MyThread(name='Thread-4', id=750) killed
reply[2]: main[1]
Sending command: threads
reply[0]: Group system:
reply[1]: (java.lang.ref.Reference$ReferenceHandler)0x17e Reference Handler running
reply[2]: (java.lang.ref.Finalizer$FinalizerThread)0x17f Finalizer cond. waiting
reply[3]: (java.lang.Thread)0x180 Signal Dispatcher running
reply[4]: Group main:
reply[5]: (java.lang.Thread)0x1 main running (at breakpoint)
reply[6]: (nsk.jdb.kill.kill002.MyThread)0x2d2 Thread-0 cond. waiting
reply[7]: (nsk.jdb.kill.kill002.MyThread)0x2eb Thread-1 cond. waiting
reply[8]: (nsk.jdb.kill.kill002.MyThread)0x2ec Thread-2 cond. waiting
reply[9]: (nsk.jdb.kill.kill002.MyThread)0x2ed Thread-3 cond. waiting
reply[10]: (nsk.jdb.kill.kill002.MyThread)0x2ee Thread-4 cond. waiting
reply[11]: Group InnocuousThreadGroup:
reply[12]: (jdk.internal.misc.InnocuousThread)0x1a4 Common-Cleaner cond. waiting
reply[13]: main[1]
Sending command: cont
receiveReply FAILED due to "nsk.share.Failure: Prompt is not received during 300200 milliseconds.".
Pending reply output follows:
reply[0]:> nsk.jdb.kill.kill002.kill002a$MyException: kill002a's Exception
reply[1]: at nsk.jdb.kill.kill002.kill002a.<clinit>(kill002a.java:49)
reply[2]: java.lang.NullPointerException: kill002a's Exception
reply[3]: at nsk.jdb.kill.kill002.kill002a.<clinit>(kill002a.java:49)
reply[4]: com.sun.jdi.IncompatibleThreadStateException: kill002a's Exception
reply[5]: at nsk.jdb.kill.kill002.kill002a.<clinit>(kill002a.java:49)
# ERROR: Caught unexpected exception while executing the test: nsk.share.Failure: Prompt is not received during 300200 milliseconds.
The following stacktrace is for failure analysis.
nsk.share.TestFailure: Caught unexpected exception while executing the test: nsk.share.Failure: Prompt is not received during 300200 milliseconds.
at nsk.share.Log.logExceptionForFailureAnalysis(Log.java:428)
at nsk.share.Log.complain(Log.java:399)
at nsk.share.jdb.JdbTest.failure(JdbTest.java:74)
at nsk.share.jdb.JdbTest.runTest(JdbTest.java:158)
at nsk.jdb.kill.kill002.kill002.run(kill002.java:76)
at nsk.jdb.kill.kill002.kill002.main(kill002.java:70)
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:566)
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:566)
at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
at java.base/java.lang.Thread.run(Thread.java:835)

Post by Chris Plummer
Hi Gary,
I think the simple prompt is meant to indicate that execution is
suspended, but there is no current thread. I don't think that is the
case here, so probably best not to use your alternate suggestion of a
simple prompt. There doesn't seem to be much purpose in the first
prompt being printed. You also seem to just be handling the situation
the same as we do for other async commands, so looks good to me.
thanks,
Chris

Post by Gary Adams
kill ... killing ... killed <prompt>
This bug was filed to cover the issue with the kill002 test,
which sometimes did not consume enough of the reply
messages after the wait for the "killed" message is observed.
When a "kill" command is issued it is processed as an asynchronous
command. The "killing" message is presented before the action is
evaluated, and the "killed" message is presented after the evaluation
returns. When the asynchronous action is completed a prompt is
displayed after restoring the current thread info when the action
was requested.
Issue: https://bugs.openjdk.java.net/browse/JDK-8211013
diff --git
a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
--- a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
+++ b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
@@ -488,6 +488,7 @@
showPrompt = false;
evaluator.commandNext();
} else if (cmd.equals("kill")) {
+ showPrompt = false; //
asynchronous command
evaluator.commandKill(t);
} else if (cmd.equals("interrupt")) {
evaluator.commandInterrupt(t);
...
main[1] threads
(java.lang.ref.Reference$ReferenceHandler)0x172 Reference Handler running
(java.lang.ref.Finalizer$FinalizerThread)0x173 Finalizer
cond. waiting
(java.lang.Thread)0x174 Signal Dispatcher running
(java.lang.Thread)0x1 main running (at breakpoint)
(nsk.jdb.kill.kill002.MyThread)0x2c9 Thread-0 cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e2 Thread-1 cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e3 Thread-2 cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e4 Thread-3 cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e5 Thread-4 cond. waiting
(jdk.internal.misc.InnocuousThread)0x19a Common-Cleaner cond.
waiting
main[1] kill 0x2c9 nsk.jdb.kill.kill002.kill002a.exceptions[0]
killing thread: Thread-0
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-0', id=713) killed
main[1] kill 0x2e2 nsk.jdb.kill.kill002.kill002a.exceptions[1]
killing thread: Thread-1
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-1', id=738) killed
main[1] kill 0x2e3 nsk.jdb.kill.kill002.kill002a.exceptions[2]
killing thread: Thread-2
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-2', id=739) killed
main[1] kill 0x2e4 nsk.jdb.kill.kill002.kill002a.exceptions[3]
killing thread: Thread-3
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-3', id=740) killed
main[1] kill 0x2e5 nsk.jdb.kill.kill002.kill002a.exceptions[4]
killing thread: Thread-4
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-4', id=741) killed
main[1] threads
...
An alternate proposal would include the simple prompt. e.g.
...
main[1] kill 0x2c9 nsk.jdb.kill.kill002.kill002a.exceptions[0]

Post by Gary Adams
killing thread: Thread-0

instance of nsk.jdb.kill.kill002.MyThread(name='Thread-0', id=713) killed
main[1] kill 0x2e2 nsk.jdb.kill.kill002.kill002a.exceptions[1]

Post by Gary Adams
killing thread: Thread-1

Test in progress.

[Gary Adams]

No kill002 failures were observed in the next 1000 testruns.
I plan to push the change below and we can see if the exceptions show up in
regular CI test runs.

Post by Gary Adams
Still seeing a 1/1000 kill002 failure on solais-sparcv9-debug.
The message waiting for "killing" is working correctly
and only one compound prompt is being delivered.
After all the killing a final cont is issued to proceed to the last
breakpoint.
The simple prompt is seen in the pending reply along with exceptions.
Need to understand why it was not a clean kill.
...
Sending command: kill 0x2ee nsk.jdb.kill.kill002.kill002a.exceptions[4]
reply[0]: killing thread: Thread-4
reply[1]: instance of nsk.jdb.kill.kill002.MyThread(name='Thread-4', id=750) killed
reply[2]: main[1]
Sending command: threads
reply[1]: (java.lang.ref.Reference$ReferenceHandler)0x17e Reference Handler running
reply[2]: (java.lang.ref.Finalizer$FinalizerThread)0x17f
Finalizer cond. waiting
reply[3]: (java.lang.Thread)0x180 Signal Dispatcher running
reply[5]: (java.lang.Thread)0x1
main running (at breakpoint)
reply[6]: (nsk.jdb.kill.kill002.MyThread)0x2d2
Thread-0 cond. waiting
reply[7]: (nsk.jdb.kill.kill002.MyThread)0x2eb
Thread-1 cond. waiting
reply[8]: (nsk.jdb.kill.kill002.MyThread)0x2ec
Thread-2 cond. waiting
reply[9]: (nsk.jdb.kill.kill002.MyThread)0x2ed
Thread-3 cond. waiting
reply[10]: (nsk.jdb.kill.kill002.MyThread)0x2ee
Thread-4 cond. waiting
reply[12]: (jdk.internal.misc.InnocuousThread)0x1a4
Common-Cleaner cond. waiting
reply[13]: main[1]
Sending command: cont
receiveReply FAILED due to "nsk.share.Failure: Prompt is not received
during 300200 milliseconds.".
reply[0]:> nsk.jdb.kill.kill002.kill002a$MyException: kill002a's Exception
reply[1]: at nsk.jdb.kill.kill002.kill002a.<clinit>(kill002a.java:49)
reply[2]: java.lang.NullPointerException: kill002a's Exception
reply[3]: at nsk.jdb.kill.kill002.kill002a.<clinit>(kill002a.java:49)
reply[4]: com.sun.jdi.IncompatibleThreadStateException: kill002a's Exception
reply[5]: at nsk.jdb.kill.kill002.kill002a.<clinit>(kill002a.java:49)
nsk.share.Failure: Prompt is not received during 300200 milliseconds.
The following stacktrace is for failure analysis.
nsk.share.TestFailure: Caught unexpected exception while executing the
test: nsk.share.Failure: Prompt is not received during 300200
milliseconds.
at nsk.share.Log.logExceptionForFailureAnalysis(Log.java:428)
at nsk.share.Log.complain(Log.java:399)
at nsk.share.jdb.JdbTest.failure(JdbTest.java:74)
at nsk.share.jdb.JdbTest.runTest(JdbTest.java:158)
at nsk.jdb.kill.kill002.kill002.run(kill002.java:76)
at nsk.jdb.kill.kill002.kill002.main(kill002.java:70)
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:566)
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:566)
at
com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
at java.base/java.lang.Thread.run(Thread.java:835)

Post by Chris Plummer
Hi Gary,
I think the simple prompt is meant to indicate that execution is
suspended, but there is no current thread. I don't think that is the
case here, so probably best not to use your alternate suggestion of a
simple prompt. There doesn't seem to be much purpose in the first
prompt being printed. You also seem to just be handling the situation
the same as we do for other async commands, so looks good to me.
thanks,
Chris

Post by Gary Adams
kill ... killing ... killed <prompt>
This bug was filed to cover the issue with the kill002 test,
which sometimes did not consume enough of the reply
messages after the wait for the "killed" message is observed.
When a "kill" command is issued it is processed as an asynchronous
command. The "killing" message is presented before the action is
evaluated, and the "killed" message is presented after the evaluation
returns. When the asynchronous action is completed a prompt is
displayed after restoring the current thread info when the action
was requested.
Issue: https://bugs.openjdk.java.net/browse/JDK-8211013
diff --git
a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
---
a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
+++
b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
@@ -488,6 +488,7 @@
showPrompt = false;
evaluator.commandNext();
} else if (cmd.equals("kill")) {
+ showPrompt = false; //
asynchronous command
evaluator.commandKill(t);
} else if (cmd.equals("interrupt")) {
evaluator.commandInterrupt(t);
...
main[1] threads
(java.lang.ref.Reference$ReferenceHandler)0x172 Reference Handler running
(java.lang.ref.Finalizer$FinalizerThread)0x173 Finalizer
cond. waiting
(java.lang.Thread)0x174 Signal Dispatcher running
(java.lang.Thread)0x1 main running (at breakpoint)
(nsk.jdb.kill.kill002.MyThread)0x2c9 Thread-0 cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e2 Thread-1 cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e3 Thread-2 cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e4 Thread-3 cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e5 Thread-4 cond. waiting
(jdk.internal.misc.InnocuousThread)0x19a Common-Cleaner cond.
waiting
main[1] kill 0x2c9 nsk.jdb.kill.kill002.kill002a.exceptions[0]
killing thread: Thread-0
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-0', id=713) killed
main[1] kill 0x2e2 nsk.jdb.kill.kill002.kill002a.exceptions[1]
killing thread: Thread-1
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-1', id=738) killed
main[1] kill 0x2e3 nsk.jdb.kill.kill002.kill002a.exceptions[2]
killing thread: Thread-2
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-2', id=739) killed
main[1] kill 0x2e4 nsk.jdb.kill.kill002.kill002a.exceptions[3]
killing thread: Thread-3
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-3', id=740) killed
main[1] kill 0x2e5 nsk.jdb.kill.kill002.kill002a.exceptions[4]
killing thread: Thread-4
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-4', id=741) killed
main[1] threads
...
An alternate proposal would include the simple prompt. e.g.
...
main[1] kill 0x2c9 nsk.jdb.kill.kill002.kill002a.exceptions[0]

Post by Gary Adams
killing thread: Thread-0

instance of nsk.jdb.kill.kill002.MyThread(name='Thread-0', id=713) killed
main[1] kill 0x2e2 nsk.jdb.kill.kill002.kill002a.exceptions[1]

Post by Gary Adams
killing thread: Thread-1

Test in progress.

[Gary Adams]

Could I get a second reviewer for this change.

Post by Chris Plummer
Hi Gary,
I think the simple prompt is meant to indicate that execution is
suspended, but there is no current thread. I don't think that is the
case here, so probably best not to use your alternate suggestion of a
simple prompt. There doesn't seem to be much purpose in the first
prompt being printed. You also seem to just be handling the situation
the same as we do for other async commands, so looks good to me.
thanks,
Chris

Post by Gary Adams
kill ... killing ... killed <prompt>
This bug was filed to cover the issue with the kill002 test,
which sometimes did not consume enough of the reply
messages after the wait for the "killed" message is observed.
When a "kill" command is issued it is processed as an asynchronous
command. The "killing" message is presented before the action is
evaluated, and the "killed" message is presented after the evaluation
returns. When the asynchronous action is completed a prompt is
displayed after restoring the current thread info when the action
was requested.
Issue: https://bugs.openjdk.java.net/browse/JDK-8211013
diff --git
a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
--- a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
+++ b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
@@ -488,6 +488,7 @@
showPrompt = false;
evaluator.commandNext();
} else if (cmd.equals("kill")) {
+ showPrompt = false; //
asynchronous command
evaluator.commandKill(t);
} else if (cmd.equals("interrupt")) {
evaluator.commandInterrupt(t);
...
main[1] threads
(java.lang.ref.Reference$ReferenceHandler)0x172 Reference Handler running
(java.lang.ref.Finalizer$FinalizerThread)0x173 Finalizer
cond. waiting
(java.lang.Thread)0x174 Signal Dispatcher running
(java.lang.Thread)0x1 main running (at breakpoint)
(nsk.jdb.kill.kill002.MyThread)0x2c9 Thread-0 cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e2 Thread-1 cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e3 Thread-2 cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e4 Thread-3 cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e5 Thread-4 cond. waiting
(jdk.internal.misc.InnocuousThread)0x19a Common-Cleaner cond.
waiting
main[1] kill 0x2c9 nsk.jdb.kill.kill002.kill002a.exceptions[0]
killing thread: Thread-0
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-0', id=713) killed
main[1] kill 0x2e2 nsk.jdb.kill.kill002.kill002a.exceptions[1]
killing thread: Thread-1
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-1', id=738) killed
main[1] kill 0x2e3 nsk.jdb.kill.kill002.kill002a.exceptions[2]
killing thread: Thread-2
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-2', id=739) killed
main[1] kill 0x2e4 nsk.jdb.kill.kill002.kill002a.exceptions[3]
killing thread: Thread-3
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-3', id=740) killed
main[1] kill 0x2e5 nsk.jdb.kill.kill002.kill002a.exceptions[4]
killing thread: Thread-4
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-4', id=741) killed
main[1] threads
...
An alternate proposal would include the simple prompt. e.g.
...
main[1] kill 0x2c9 nsk.jdb.kill.kill002.kill002a.exceptions[0]

Post by Gary Adams
killing thread: Thread-0

instance of nsk.jdb.kill.kill002.MyThread(name='Thread-0', id=713) killed
main[1] kill 0x2e2 nsk.jdb.kill.kill002.kill002a.exceptions[1]

Post by Gary Adams
killing thread: Thread-1

Test in progress.

[JC Beyler]

Hi Gary,

Looks good to me (not an official reviewer though),
Jc

Post by Gary Adams
Could I get a second reviewer for this change.

Post by Chris Plummer
Hi Gary,
I think the simple prompt is meant to indicate that execution is
suspended, but there is no current thread. I don't think that is the
case here, so probably best not to use your alternate suggestion of a
simple prompt. There doesn't seem to be much purpose in the first
prompt being printed. You also seem to just be handling the situation
the same as we do for other async commands, so looks good to me.
thanks,
Chris

Post by Gary Adams
kill ... killing ... killed <prompt>
This bug was filed to cover the issue with the kill002 test,
which sometimes did not consume enough of the reply
messages after the wait for the "killed" message is observed.
When a "kill" command is issued it is processed as an asynchronous
command. The "killing" message is presented before the action is
evaluated, and the "killed" message is presented after the evaluation
returns. When the asynchronous action is completed a prompt is
displayed after restoring the current thread info when the action
was requested.
Issue: https://bugs.openjdk.java.net/browse/JDK-8211013
diff --git
a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
--- a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
+++ b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
@@ -488,6 +488,7 @@
showPrompt = false;
evaluator.commandNext();
} else if (cmd.equals("kill")) {
+ showPrompt = false; //
asynchronous command
evaluator.commandKill(t);
} else if (cmd.equals("interrupt")) {
evaluator.commandInterrupt(t);
...
main[1] threads
(java.lang.ref.Reference$ReferenceHandler)0x172 Reference Handler running
(java.lang.ref.Finalizer$FinalizerThread)0x173 Finalizer
cond. waiting
(java.lang.Thread)0x174 Signal Dispatcher running
(java.lang.Thread)0x1 main running (at breakpoint)
(nsk.jdb.kill.kill002.MyThread)0x2c9 Thread-0 cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e2 Thread-1 cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e3 Thread-2 cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e4 Thread-3 cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e5 Thread-4 cond. waiting
(jdk.internal.misc.InnocuousThread)0x19a Common-Cleaner cond.
waiting
main[1] kill 0x2c9 nsk.jdb.kill.kill002.kill002a.exceptions[0]
killing thread: Thread-0
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-0', id=713) killed
main[1] kill 0x2e2 nsk.jdb.kill.kill002.kill002a.exceptions[1]
killing thread: Thread-1
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-1', id=738) killed
main[1] kill 0x2e3 nsk.jdb.kill.kill002.kill002a.exceptions[2]
killing thread: Thread-2
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-2', id=739) killed
main[1] kill 0x2e4 nsk.jdb.kill.kill002.kill002a.exceptions[3]
killing thread: Thread-3
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-3', id=740) killed
main[1] kill 0x2e5 nsk.jdb.kill.kill002.kill002a.exceptions[4]
killing thread: Thread-4
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-4', id=741) killed
main[1] threads
...
An alternate proposal would include the simple prompt. e.g.
...
main[1] kill 0x2c9 nsk.jdb.kill.kill002.kill002a.exceptions[0]

Post by Gary Adams
killing thread: Thread-0

instance of nsk.jdb.kill.kill002.MyThread(name='Thread-0', id=713) killed
main[1] kill 0x2e2 nsk.jdb.kill.kill002.kill002a.exceptions[1]

Post by Gary Adams
killing thread: Thread-1

Test in progress.

[Daniil Titov]

Hi Gary,

This change looks OK to me.

Bets regards,
Daniil

On 10/23/18, 11:08 AM, "serviceability-dev on behalf of Gary Adams" <serviceability-dev-***@openjdk.java.net on behalf of ***@oracle.com> wrote:

Could I get a second reviewer for this change.

Post by Chris Plummer
Hi Gary,
I think the simple prompt is meant to indicate that execution is
suspended, but there is no current thread. I don't think that is the
case here, so probably best not to use your alternate suggestion of a
simple prompt. There doesn't seem to be much purpose in the first
prompt being printed. You also seem to just be handling the situation
the same as we do for other async commands, so looks good to me.
thanks,
Chris

Post by Gary Adams
kill ... killing ... killed <prompt>
This bug was filed to cover the issue with the kill002 test,
which sometimes did not consume enough of the reply
messages after the wait for the "killed" message is observed.
When a "kill" command is issued it is processed as an asynchronous
command. The "killing" message is presented before the action is
evaluated, and the "killed" message is presented after the evaluation
returns. When the asynchronous action is completed a prompt is
displayed after restoring the current thread info when the action
was requested.
Issue: https://bugs.openjdk.java.net/browse/JDK-8211013
diff --git
a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
--- a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
+++ b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
@@ -488,6 +488,7 @@
showPrompt = false;
evaluator.commandNext();
} else if (cmd.equals("kill")) {
+ showPrompt = false; //
asynchronous command
evaluator.commandKill(t);
} else if (cmd.equals("interrupt")) {
evaluator.commandInterrupt(t);
...
main[1] threads
(java.lang.ref.Reference$ReferenceHandler)0x172 Reference Handler running
(java.lang.ref.Finalizer$FinalizerThread)0x173 Finalizer
cond. waiting
(java.lang.Thread)0x174 Signal Dispatcher running
(java.lang.Thread)0x1 main running (at breakpoint)
(nsk.jdb.kill.kill002.MyThread)0x2c9 Thread-0 cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e2 Thread-1 cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e3 Thread-2 cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e4 Thread-3 cond. waiting
(nsk.jdb.kill.kill002.MyThread)0x2e5 Thread-4 cond. waiting
(jdk.internal.misc.InnocuousThread)0x19a Common-Cleaner cond.
waiting
main[1] kill 0x2c9 nsk.jdb.kill.kill002.kill002a.exceptions[0]
killing thread: Thread-0
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-0', id=713) killed
main[1] kill 0x2e2 nsk.jdb.kill.kill002.kill002a.exceptions[1]
killing thread: Thread-1
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-1', id=738) killed
main[1] kill 0x2e3 nsk.jdb.kill.kill002.kill002a.exceptions[2]
killing thread: Thread-2
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-2', id=739) killed
main[1] kill 0x2e4 nsk.jdb.kill.kill002.kill002a.exceptions[3]
killing thread: Thread-3
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-3', id=740) killed
main[1] kill 0x2e5 nsk.jdb.kill.kill002.kill002a.exceptions[4]
killing thread: Thread-4
instance of nsk.jdb.kill.kill002.MyThread(name='Thread-4', id=741) killed
main[1] threads
...
An alternate proposal would include the simple prompt. e.g.
...
main[1] kill 0x2c9 nsk.jdb.kill.kill002.kill002a.exceptions[0]

Post by Gary Adams
killing thread: Thread-0

instance of nsk.jdb.kill.kill002.MyThread(name='Thread-0', id=713) killed
main[1] kill 0x2e2 nsk.jdb.kill.kill002.kill002a.exceptions[1]

Post by Gary Adams
killing thread: Thread-1

Test in progress.