RFR: JDK-8211013: TESTBUG] nsk/jdb/kill/kill002 wait for message and prompt
Gary Adams
gary.adams at oracle.com
Thu Oct 18 11:55:41 UTC 2018
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.
On 10/16/18, 7:31 AM, Gary Adams wrote:
> 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.
>>
>>
>
More information about the serviceability-dev
mailing list