RFR: JDK-8211013: TESTBUG] nsk/jdb/kill/kill002 wait for message and prompt
Gary Adams
gary.adams at oracle.com
Tue Oct 23 18:07:32 UTC 2018
Could I get a second reviewer for this change.
On 10/15/18, 3:16 PM, Chris Plummer wrote:
> 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
>
> On 10/15/18 10:44 AM, Gary Adams wrote:
>> 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.
>
>
More information about the serviceability-dev
mailing list