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

Tue Oct 16 11:31:05 UTC 2018

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)

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.
>
>