Discussion:
RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD
(too old to reply)
Daniil Titov
2018-10-12 00:07:11 UTC
Permalink
Please review the change that fixes the issue with missing prompt in jdb when a breakpoint is hit and the suspend policy is set to stop the thread only.

Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
Issue: https://bugs.openjdk.java.net/browse/JDK-8211736

Thanks!
--Daniil
JC Beyler
2018-10-12 02:17:02 UTC
Permalink
Hi Daniil,

Looks good to me. I saw a really small nit:
http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS ,bpLine));

There is a space after the '('.

No need to send a new webrev for that evidently :),
Jc

On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov <***@oracle.com>
wrote:

> Please review the change that fixes the issue with missing prompt in jdb
> when a breakpoint is hit and the suspend policy is set to stop the thread
> only.
>
> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>
> Thanks!
> --Daniil
>
>
>
>

--

Thanks,
Jc
Daniil Titov
2018-10-12 03:02:26 UTC
Permalink
Thank you,  JC!



Please review an updated version of the patch that fixes newly added test for Windows platform  (now it uses system dependent line separator string).



Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/

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



Best regards,

--Daniil



From: JC Beyler <***@google.com>
Date: Thursday, October 11, 2018 at 7:17 PM
To: <***@oracle.com>
Cc: <serviceability-***@openjdk.java.net>
Subject: Re: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD



Hi Daniil,



Looks good to me. I saw a really small nit:

http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html

70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS ,bpLine));



There is a space after the '('.



No need to send a new webrev for that evidently :),

Jc



On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov <***@oracle.com> wrote:

Please review the change that fixes the issue with missing prompt in jdb when a breakpoint is hit and the suspend policy is set to stop the thread only.

Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
Issue: https://bugs.openjdk.java.net/browse/JDK-8211736

Thanks!
--Daniil






--



Thanks,

Jc
Chris Plummer
2018-10-12 05:00:16 UTC
Permalink
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Daniil,<br>
<br>
Can you send output from an example jdb session?<br>
<br>
Do you think maybe we should also call printCurrentLocation() when
the suspend policy is NONE?<br>
<br>
There's a typo in the following line. The space is on the wrong
side of the comma.<br>
<br>
  72         jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
,bpLine));<br>
<br>
thanks,<br>
<br>
Chris<br>
<br>
On 10/11/18 8:02 PM, Daniil Titov wrote:<br>
</div>
<blockquote type="cite"
cite="mid:00A38007-4C48-47F6-BE85-***@oracle.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
<div class="WordSection1">
<p class="MsoNormal">Thank you,  JC!<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Please review an updated version of the
patch that fixes newly added test for Windows platform  (now
it uses system dependent line separator string).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="ES">Webrev:</span><span
lang="ES"> </span><a
href="http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/"
moz-do-not-send="true"><span lang="ES">http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/</span></a><span
lang="ES"><o:p></o:p></span></p>
<p class="MsoNormal">Issue: <a
href="https://bugs.openjdk.java.net/browse/JDK-8211736"
target="_blank" moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8211736</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best regards,<o:p></o:p></p>
<p class="MsoNormal">--Daniil<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:12.0pt;color:black">From: </span></b><span
style="font-size:12.0pt;color:black">JC Beyler
<a class="moz-txt-link-rfc2396E" href="mailto:***@google.com">&lt;***@google.com&gt;</a><br>
<b>Date: </b>Thursday, October 11, 2018 at 7:17 PM<br>
<b>To: </b><a class="moz-txt-link-rfc2396E" href="mailto:***@oracle.com">&lt;***@oracle.com&gt;</a><br>
<b>Cc: </b><a class="moz-txt-link-rfc2396E" href="mailto:serviceability-***@openjdk.java.net">&lt;serviceability-***@openjdk.java.net&gt;</a><br>
<b>Subject: </b>Re: RFR 8211736: jdb doesn't print prompt
when breakpoint is hit and suspend policy is
STOP_EVENT_THREAD<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">Hi Daniil,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Looks good to me. I saw a really
small nit:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a
href="http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html"
moz-do-not-send="true">http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">70       
 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS
,bpLine));<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">There is a space after the '('.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">No need to send a new webrev for
that evidently :),<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Jc<o:p></o:p></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, Oct 11, 2018 at 5:07 PM Daniil
Titov &lt;<a href="mailto:***@oracle.com"
moz-do-not-send="true">***@oracle.com</a>&gt;
wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-bottom:12.0pt">Please
review the change that fixes the issue with missing prompt
in jdb when a breakpoint is hit and the suspend policy is
set to stop the thread only.<br>
<br>
Webrev: <a
href="http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01"
target="_blank" moz-do-not-send="true">http://cr.openjdk.java.net/~dtitov/8211736/webrev.01</a><br>
Issue: <a
href="https://bugs.openjdk.java.net/browse/JDK-8211736"
target="_blank" moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8211736</a><br>
<br>
Thanks!<br>
--Daniil<br>
<br>
<br>
<o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<div>
<p class="MsoNormal">Jc<o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>
Alex Menkov
2018-10-12 16:52:25 UTC
Permalink
Hi Daniil,

1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL

2) wrong indent in JdbStopThreadTest.java:
36 import lib.jdb.JdbCommand;
37 import lib.jdb.JdbTest;

3) I think it would be better to make waitForSimplePrompt property of
JdbCommand (like JdbCommand.allowExit)

jdb.command(JdbCommand.run().replyIsSimplePrompt());
looks much clearer than
jdb.command(JdbCommand.run(), true);

4) (TTY.java)
MessageOutput.lnprint("Breakpoint hit:");
+ // Print current location and prompt if suspend policy is
SUSPEND_EVENT_THREAD.
+ // In case of SUSPEND_ALL policy this is handled by vmInterrupted()
method.
+ if (be.request().suspendPolicy() == EventRequest.SUSPEND_EVENT_THREAD) {
+ printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
+ MessageOutput.printPrompt();
+ }
We have 3 separate outputs.
If we have several concurrent threads, we can easy get mess of outputs
from different threads.
I think it would be better to print everything in a single chunk.
I suppose TTY has other places with similar "non-atomic" output, so
maybe revising TTY output should be handled by separate issue.

--alex

On 10/11/2018 22:00, Chris Plummer wrote:
> Hi Daniil,
>
> Can you send output from an example jdb session?
>
> Do you think maybe we should also call printCurrentLocation() when the
> suspend policy is NONE?
>
> There's a typo in the following line. The space is on the wrong side of
> the comma.
>
>   72         jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS ,bpLine));
>
> thanks,
>
> Chris
>
> On 10/11/18 8:02 PM, Daniil Titov wrote:
>>
>> Thank you,  JC!
>>
>> Please review an updated version of the patch that fixes newly added
>> test for Windows platform  (now it uses system dependent line
>> separator string).
>>
>> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>
>> Best regards,
>>
>> --Daniil
>>
>> *From: *JC Beyler <***@google.com>
>> *Date: *Thursday, October 11, 2018 at 7:17 PM
>> *To: *<***@oracle.com>
>> *Cc: *<serviceability-***@openjdk.java.net>
>> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when breakpoint
>> is hit and suspend policy is STOP_EVENT_THREAD
>>
>> Hi Daniil,
>>
>> Looks good to me. I saw a really small nit:
>>
>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
>>
>> 70  jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS ,bpLine));
>>
>> There is a space after the '('.
>>
>> No need to send a new webrev for that evidently :),
>>
>> Jc
>>
>> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
>> <***@oracle.com <mailto:***@oracle.com>> wrote:
>>
>> Please review the change that fixes the issue with missing prompt
>> in jdb when a breakpoint is hit and the suspend policy is set to
>> stop the thread only.
>>
>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>
>> Thanks!
>> --Daniil
>>
>>
>>
>> --
>>
>> Thanks,
>>
>> Jc
>>
>
Daniil Titov
2018-10-12 17:30:46 UTC
Permalink
Hi Chris and Alex,

Please find below the output of the debug session:
===BEGIN===
jdb ThreadObj
Initializing jdb ...
> stop thread at ThreadObj:4
Deferring breakpoint ThreadObj:4.
It will be set after the class is loaded.
> run
run ThreadObj
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
>
VM Started: Set deferred breakpoint ThreadObj:4

Breakpoint hit: "thread=main", ThreadObj.main(), line=4 bci=4
4 print(thread);

> thread 1
main[1] cont
> Thread[main,5,main]

The application exited
===END===

The following commands were entered:
1) stop thread at ThreadObj:4
2) run
3) thread 1
4) cont

We cannot call printCurrentLocation() for the case when the suspend policy is set to SUSPEND_NONE, since in this case threadInfo.getCurrentFrame() does not return the correct frame. Instead, for this case (when the suspend policy is set to SUSPEND_NONE) I plan to print the breakpoint location using the location returned by BreakPointEvent.location() method. I will also add the new test for SUSPEND_NONE suspend policy case and address Alex's suggestions in the new webrev I will send later.

Thanks,
Daniil

On 10/12/18, 9:52 AM, "Alex Menkov" <***@oracle.com> wrote:

Hi Daniil,

1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL

2) wrong indent in JdbStopThreadTest.java:
36 import lib.jdb.JdbCommand;
37 import lib.jdb.JdbTest;

3) I think it would be better to make waitForSimplePrompt property of
JdbCommand (like JdbCommand.allowExit)

jdb.command(JdbCommand.run().replyIsSimplePrompt());
looks much clearer than
jdb.command(JdbCommand.run(), true);

4) (TTY.java)
MessageOutput.lnprint("Breakpoint hit:");
+ // Print current location and prompt if suspend policy is
SUSPEND_EVENT_THREAD.
+ // In case of SUSPEND_ALL policy this is handled by vmInterrupted()
method.
+ if (be.request().suspendPolicy() == EventRequest.SUSPEND_EVENT_THREAD) {
+ printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
+ MessageOutput.printPrompt();
+ }
We have 3 separate outputs.
If we have several concurrent threads, we can easy get mess of outputs
from different threads.
I think it would be better to print everything in a single chunk.
I suppose TTY has other places with similar "non-atomic" output, so
maybe revising TTY output should be handled by separate issue.

--alex

On 10/11/2018 22:00, Chris Plummer wrote:
> Hi Daniil,
>
> Can you send output from an example jdb session?
>
> Do you think maybe we should also call printCurrentLocation() when the
> suspend policy is NONE?
>
> There's a typo in the following line. The space is on the wrong side of
> the comma.
>
> 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS ,bpLine));
>
> thanks,
>
> Chris
>
> On 10/11/18 8:02 PM, Daniil Titov wrote:
>>
>> Thank you, JC!
>>
>> Please review an updated version of the patch that fixes newly added
>> test for Windows platform (now it uses system dependent line
>> separator string).
>>
>> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>
>> Best regards,
>>
>> --Daniil
>>
>> *From: *JC Beyler <***@google.com>
>> *Date: *Thursday, October 11, 2018 at 7:17 PM
>> *To: *<***@oracle.com>
>> *Cc: *<serviceability-***@openjdk.java.net>
>> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when breakpoint
>> is hit and suspend policy is STOP_EVENT_THREAD
>>
>> Hi Daniil,
>>
>> Looks good to me. I saw a really small nit:
>>
>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
>>
>> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS ,bpLine));
>>
>> There is a space after the '('.
>>
>> No need to send a new webrev for that evidently :),
>>
>> Jc
>>
>> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
>> <***@oracle.com <mailto:***@oracle.com>> wrote:
>>
>> Please review the change that fixes the issue with missing prompt
>> in jdb when a breakpoint is hit and the suspend policy is set to
>> stop the thread only.
>>
>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>
>> Thanks!
>> --Daniil
>>
>>
>>
>> --
>>
>> Thanks,
>>
>> Jc
>>
>
Chris Plummer
2018-10-12 19:32:57 UTC
Permalink
Hi Daniil,

Thanks for the debug session. I did make me realize one flaw. The
"thread" command requires a thread number, but the breakpoint output
only includes the thread name. I wonder if we could also include the
thread number, although we'd have to be careful not to break any
existing tests that are parsing the output. I guess the other option for
the user is to use the "threads" command to map the thread name to a
thread number.

thanks,

Chris

On 10/12/18 10:30 AM, Daniil Titov wrote:
> Hi Chris and Alex,
>
> Please find below the output of the debug session:
> ===BEGIN===
> jdb ThreadObj
> Initializing jdb ...
>> stop thread at ThreadObj:4
> Deferring breakpoint ThreadObj:4.
> It will be set after the class is loaded.
>> run
> run ThreadObj
> Set uncaught java.lang.Throwable
> Set deferred uncaught java.lang.Throwable
> VM Started: Set deferred breakpoint ThreadObj:4
>
> Breakpoint hit: "thread=main", ThreadObj.main(), line=4 bci=4
> 4 print(thread);
>
>> thread 1
> main[1] cont
>> Thread[main,5,main]
> The application exited
> ===END===
>
> The following commands were entered:
> 1) stop thread at ThreadObj:4
> 2) run
> 3) thread 1
> 4) cont
>
> We cannot call printCurrentLocation() for the case when the suspend policy is set to SUSPEND_NONE, since in this case threadInfo.getCurrentFrame() does not return the correct frame. Instead, for this case (when the suspend policy is set to SUSPEND_NONE) I plan to print the breakpoint location using the location returned by BreakPointEvent.location() method. I will also add the new test for SUSPEND_NONE suspend policy case and address Alex's suggestions in the new webrev I will send later.
>
> Thanks,
> Daniil
>
> On 10/12/18, 9:52 AM, "Alex Menkov" <***@oracle.com> wrote:
>
> Hi Daniil,
>
> 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL
>
> 2) wrong indent in JdbStopThreadTest.java:
> 36 import lib.jdb.JdbCommand;
> 37 import lib.jdb.JdbTest;
>
> 3) I think it would be better to make waitForSimplePrompt property of
> JdbCommand (like JdbCommand.allowExit)
>
> jdb.command(JdbCommand.run().replyIsSimplePrompt());
> looks much clearer than
> jdb.command(JdbCommand.run(), true);
>
> 4) (TTY.java)
> MessageOutput.lnprint("Breakpoint hit:");
> + // Print current location and prompt if suspend policy is
> SUSPEND_EVENT_THREAD.
> + // In case of SUSPEND_ALL policy this is handled by vmInterrupted()
> method.
> + if (be.request().suspendPolicy() == EventRequest.SUSPEND_EVENT_THREAD) {
> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
> + MessageOutput.printPrompt();
> + }
> We have 3 separate outputs.
> If we have several concurrent threads, we can easy get mess of outputs
> from different threads.
> I think it would be better to print everything in a single chunk.
> I suppose TTY has other places with similar "non-atomic" output, so
> maybe revising TTY output should be handled by separate issue.
>
> --alex
>
> On 10/11/2018 22:00, Chris Plummer wrote:
> > Hi Daniil,
> >
> > Can you send output from an example jdb session?
> >
> > Do you think maybe we should also call printCurrentLocation() when the
> > suspend policy is NONE?
> >
> > There's a typo in the following line. The space is on the wrong side of
> > the comma.
> >
> > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS ,bpLine));
> >
> > thanks,
> >
> > Chris
> >
> > On 10/11/18 8:02 PM, Daniil Titov wrote:
> >>
> >> Thank you, JC!
> >>
> >> Please review an updated version of the patch that fixes newly added
> >> test for Windows platform (now it uses system dependent line
> >> separator string).
> >>
> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
> >>
> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> >>
> >> Best regards,
> >>
> >> --Daniil
> >>
> >> *From: *JC Beyler <***@google.com>
> >> *Date: *Thursday, October 11, 2018 at 7:17 PM
> >> *To: *<***@oracle.com>
> >> *Cc: *<serviceability-***@openjdk.java.net>
> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when breakpoint
> >> is hit and suspend policy is STOP_EVENT_THREAD
> >>
> >> Hi Daniil,
> >>
> >> Looks good to me. I saw a really small nit:
> >>
> >> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
> >>
> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS ,bpLine));
> >>
> >> There is a space after the '('.
> >>
> >> No need to send a new webrev for that evidently :),
> >>
> >> Jc
> >>
> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
> >> <***@oracle.com <mailto:***@oracle.com>> wrote:
> >>
> >> Please review the change that fixes the issue with missing prompt
> >> in jdb when a breakpoint is hit and the suspend policy is set to
> >> stop the thread only.
> >>
> >> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> >>
> >> Thanks!
> >> --Daniil
> >>
> >>
> >>
> >> --
> >>
> >> Thanks,
> >>
> >> Jc
> >>
> >
>
>
>
Daniil Titov
2018-10-17 03:59:36 UTC
Permalink
Hi Alex, Chris and JC,

Please review an updated version of the patch that addresses these issues.

Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
Issue: https://bugs.openjdk.java.net/browse/JDK-8211736

Thanks!
--Daniil


On 10/12/18, 9:52 AM, "Alex Menkov" <***@oracle.com> wrote:

Hi Daniil,

1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL

2) wrong indent in JdbStopThreadTest.java:
36 import lib.jdb.JdbCommand;
37 import lib.jdb.JdbTest;

3) I think it would be better to make waitForSimplePrompt property of
JdbCommand (like JdbCommand.allowExit)

jdb.command(JdbCommand.run().replyIsSimplePrompt());
looks much clearer than
jdb.command(JdbCommand.run(), true);

4) (TTY.java)
MessageOutput.lnprint("Breakpoint hit:");
+ // Print current location and prompt if suspend policy is
SUSPEND_EVENT_THREAD.
+ // In case of SUSPEND_ALL policy this is handled by vmInterrupted()
method.
+ if (be.request().suspendPolicy() == EventRequest.SUSPEND_EVENT_THREAD) {
+ printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
+ MessageOutput.printPrompt();
+ }
We have 3 separate outputs.
If we have several concurrent threads, we can easy get mess of outputs
from different threads.
I think it would be better to print everything in a single chunk.
I suppose TTY has other places with similar "non-atomic" output, so
maybe revising TTY output should be handled by separate issue.

--alex

On 10/11/2018 22:00, Chris Plummer wrote:
> Hi Daniil,
>
> Can you send output from an example jdb session?
>
> Do you think maybe we should also call printCurrentLocation() when the
> suspend policy is NONE?
>
> There's a typo in the following line. The space is on the wrong side of
> the comma.
>
> 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS ,bpLine));
>
> thanks,
>
> Chris
>
> On 10/11/18 8:02 PM, Daniil Titov wrote:
>>
>> Thank you, JC!
>>
>> Please review an updated version of the patch that fixes newly added
>> test for Windows platform (now it uses system dependent line
>> separator string).
>>
>> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>
>> Best regards,
>>
>> --Daniil
>>
>> *From: *JC Beyler <***@google.com>
>> *Date: *Thursday, October 11, 2018 at 7:17 PM
>> *To: *<***@oracle.com>
>> *Cc: *<serviceability-***@openjdk.java.net>
>> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when breakpoint
>> is hit and suspend policy is STOP_EVENT_THREAD
>>
>> Hi Daniil,
>>
>> Looks good to me. I saw a really small nit:
>>
>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
>>
>> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS ,bpLine));
>>
>> There is a space after the '('.
>>
>> No need to send a new webrev for that evidently :),
>>
>> Jc
>>
>> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
>> <***@oracle.com <mailto:***@oracle.com>> wrote:
>>
>> Please review the change that fixes the issue with missing prompt
>> in jdb when a breakpoint is hit and the suspend policy is set to
>> stop the thread only.
>>
>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>
>> Thanks!
>> --Daniil
>>
>>
>>
>> --
>>
>> Thanks,
>>
>> Jc
>>
>
Chris Plummer
2018-10-17 17:47:03 UTC
Permalink
Hi Alex,

I think the tty buffering should be a separate bug fix, and I'd also
like input from Gary on it since he had tried something similar at one
point. It should probably also include a multithread test to prove the
fix is working (after first getting the test to fail without the changes).

thanks,

Chris

On 10/16/18 8:59 PM, Daniil Titov wrote:
> Hi Alex, Chris and JC,
>
> Please review an updated version of the patch that addresses these issues.
>
> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>
> Thanks!
> --Daniil
>
>
> On 10/12/18, 9:52 AM, "Alex Menkov" <***@oracle.com> wrote:
>
> Hi Daniil,
>
> 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL
>
> 2) wrong indent in JdbStopThreadTest.java:
> 36 import lib.jdb.JdbCommand;
> 37 import lib.jdb.JdbTest;
>
> 3) I think it would be better to make waitForSimplePrompt property of
> JdbCommand (like JdbCommand.allowExit)
>
> jdb.command(JdbCommand.run().replyIsSimplePrompt());
> looks much clearer than
> jdb.command(JdbCommand.run(), true);
>
> 4) (TTY.java)
> MessageOutput.lnprint("Breakpoint hit:");
> + // Print current location and prompt if suspend policy is
> SUSPEND_EVENT_THREAD.
> + // In case of SUSPEND_ALL policy this is handled by vmInterrupted()
> method.
> + if (be.request().suspendPolicy() == EventRequest.SUSPEND_EVENT_THREAD) {
> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
> + MessageOutput.printPrompt();
> + }
> We have 3 separate outputs.
> If we have several concurrent threads, we can easy get mess of outputs
> from different threads.
> I think it would be better to print everything in a single chunk.
> I suppose TTY has other places with similar "non-atomic" output, so
> maybe revising TTY output should be handled by separate issue.
>
> --alex
>
> On 10/11/2018 22:00, Chris Plummer wrote:
> > Hi Daniil,
> >
> > Can you send output from an example jdb session?
> >
> > Do you think maybe we should also call printCurrentLocation() when the
> > suspend policy is NONE?
> >
> > There's a typo in the following line. The space is on the wrong side of
> > the comma.
> >
> > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS ,bpLine));
> >
> > thanks,
> >
> > Chris
> >
> > On 10/11/18 8:02 PM, Daniil Titov wrote:
> >>
> >> Thank you, JC!
> >>
> >> Please review an updated version of the patch that fixes newly added
> >> test for Windows platform (now it uses system dependent line
> >> separator string).
> >>
> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
> >>
> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> >>
> >> Best regards,
> >>
> >> --Daniil
> >>
> >> *From: *JC Beyler <***@google.com>
> >> *Date: *Thursday, October 11, 2018 at 7:17 PM
> >> *To: *<***@oracle.com>
> >> *Cc: *<serviceability-***@openjdk.java.net>
> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when breakpoint
> >> is hit and suspend policy is STOP_EVENT_THREAD
> >>
> >> Hi Daniil,
> >>
> >> Looks good to me. I saw a really small nit:
> >>
> >> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
> >>
> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS ,bpLine));
> >>
> >> There is a space after the '('.
> >>
> >> No need to send a new webrev for that evidently :),
> >>
> >> Jc
> >>
> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
> >> <***@oracle.com <mailto:***@oracle.com>> wrote:
> >>
> >> Please review the change that fixes the issue with missing prompt
> >> in jdb when a breakpoint is hit and the suspend policy is set to
> >> stop the thread only.
> >>
> >> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> >>
> >> Thanks!
> >> --Daniil
> >>
> >>
> >>
> >> --
> >>
> >> Thanks,
> >>
> >> Jc
> >>
> >
>
>
>
Alex Menkov
2018-10-17 22:31:50 UTC
Permalink
Hi Daniil, Chris,

As far as I understand, the fix does not completely fixes all
"non-atomic" output issues (at least TTY.executeCommand still prints
prompt separately), so I agree that handle it as separate issue would be
better.
Unfortunately I don't know Gary's ideas for the issue.

About the fix for print prompt:
1) TTY.java:
+ // Print current location if suspend policy is SUSPEND_NONE
I suppose you mean "Print breakpoint location"

2) Does it make sense to use printCurrentLocation for SUSPEND_EVENT_THREAD?
Is it expected to print something different from printBreakpointLocation?

3) I don't quite understand why we don't print simple prompt for
SUSPEND_NONE. IIUC jdb can accept new command in both
SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb waits
for next command, right?)

4) JdbStopThreadTest.java
New line line in Java regexp is "\\R"

--alex

On 10/17/2018 10:47, Chris Plummer wrote:
> Hi Alex,
>
> I think the tty buffering should be a separate bug fix, and I'd also
> like input from Gary on it since he had tried something similar at one
> point. It should probably also include a multithread test to prove the
> fix is working (after first getting the test to fail without the changes).
>
> thanks,
>
> Chris
>
> On 10/16/18 8:59 PM, Daniil Titov wrote:
>> Hi Alex, Chris and JC,
>>
>> Please review an updated version of the patch that addresses these
>> issues.
>>
>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
>> Issue:  https://bugs.openjdk.java.net/browse/JDK-8211736
>>
>> Thanks!
>> --Daniil
>>
>>
>> On 10/12/18, 9:52 AM, "Alex Menkov" <***@oracle.com> wrote:
>>
>>      Hi Daniil,
>>      1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL
>>      2) wrong indent in JdbStopThreadTest.java:
>>         36         import lib.jdb.JdbCommand;
>>         37         import lib.jdb.JdbTest;
>>      3) I think it would be better to make waitForSimplePrompt
>> property of
>>      JdbCommand (like JdbCommand.allowExit)
>>      jdb.command(JdbCommand.run().replyIsSimplePrompt());
>>      looks much clearer than
>>      jdb.command(JdbCommand.run(), true);
>>      4) (TTY.java)
>>          MessageOutput.lnprint("Breakpoint hit:");
>>      +  // Print current location and prompt if suspend policy is
>>      SUSPEND_EVENT_THREAD.
>>      +  // In case of SUSPEND_ALL policy this is handled by
>> vmInterrupted()
>>      method.
>>      +  if (be.request().suspendPolicy() ==
>> EventRequest.SUSPEND_EVENT_THREAD) {
>>      +      printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
>>      +      MessageOutput.printPrompt();
>>      +  }
>>      We have 3 separate outputs.
>>      If we have several concurrent threads, we can easy get mess of
>> outputs
>>      from different threads.
>>      I think it would be better to print everything in a single chunk.
>>      I suppose TTY has other places with similar "non-atomic" output, so
>>      maybe revising TTY output should be handled by separate issue.
>>      --alex
>>      On 10/11/2018 22:00, Chris Plummer wrote:
>>      > Hi Daniil,
>>      >
>>      > Can you send output from an example jdb session?
>>      >
>>      > Do you think maybe we should also call printCurrentLocation()
>> when the
>>      > suspend policy is NONE?
>>      >
>>      > There's a typo in the following line. The space is on the wrong
>> side of
>>      > the comma.
>>      >
>>      >    72
>> jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS ,bpLine));
>>      >
>>      > thanks,
>>      >
>>      > Chris
>>      >
>>      > On 10/11/18 8:02 PM, Daniil Titov wrote:
>>      >>
>>      >> Thank you,  JC!
>>      >>
>>      >> Please review an updated version of the patch that fixes newly
>> added
>>      >> test for Windows platform  (now it uses system dependent line
>>      >> separator string).
>>      >>
>>      >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
>>      >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
>>      >>
>>      >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>      >>
>>      >> Best regards,
>>      >>
>>      >> --Daniil
>>      >>
>>      >> *From: *JC Beyler <***@google.com>
>>      >> *Date: *Thursday, October 11, 2018 at 7:17 PM
>>      >> *To: *<***@oracle.com>
>>      >> *Cc: *<serviceability-***@openjdk.java.net>
>>      >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when
>> breakpoint
>>      >> is hit and suspend policy is STOP_EVENT_THREAD
>>      >>
>>      >> Hi Daniil,
>>      >>
>>      >> Looks good to me. I saw a really small nit:
>>      >>
>>      >>
>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
>>
>>      >>
>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
>>
>>      >>
>>      >> 70  jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS
>> ,bpLine));
>>      >>
>>      >> There is a space after the '('.
>>      >>
>>      >> No need to send a new webrev for that evidently :),
>>      >>
>>      >> Jc
>>      >>
>>      >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
>>      >> <***@oracle.com <mailto:***@oracle.com>>
>> wrote:
>>      >>
>>      >>     Please review the change that fixes the issue with missing
>> prompt
>>      >>     in jdb when a breakpoint is hit and the suspend policy is
>> set to
>>      >>     stop the thread only.
>>      >>
>>      >>     Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
>>      >>     <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
>>      >>     Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>      >>
>>      >>     Thanks!
>>      >>     --Daniil
>>      >>
>>      >>
>>      >>
>>      >> --
>>      >>
>>      >> Thanks,
>>      >>
>>      >> Jc
>
Chris Plummer
2018-10-17 22:52:53 UTC
Permalink
What is the jdb state for a breakpoint with SUSPEND_NONE? Can you
actually type in commands even though no threads are suspended?

Chris

On 10/17/18 3:31 PM, Alex Menkov wrote:
> Hi Daniil, Chris,
>
> As far as I understand, the fix does not completely fixes all
> "non-atomic" output issues (at least TTY.executeCommand still prints
> prompt separately), so I agree that handle it as separate issue would
> be better.
> Unfortunately I don't know Gary's ideas for the issue.
>
> About the fix for print prompt:
> 1) TTY.java:
> +            // Print current location if suspend policy is SUSPEND_NONE
> I suppose you mean "Print breakpoint location"
>
> 2) Does it make sense to use printCurrentLocation for
> SUSPEND_EVENT_THREAD?
> Is it expected to print something different from printBreakpointLocation?
>
> 3) I don't quite understand why we don't print simple prompt for
> SUSPEND_NONE. IIUC jdb can accept new command in both
> SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb
> waits for next command, right?)
>
> 4) JdbStopThreadTest.java
> New line line in Java regexp is "\\R"
>
> --alex
>
> On 10/17/2018 10:47, Chris Plummer wrote:
>> Hi Alex,
>>
>> I think the tty buffering should be a separate bug fix, and I'd also
>> like input from Gary on it since he had tried something similar at
>> one point. It should probably also include a multithread test to
>> prove the fix is working (after first getting the test to fail
>> without the changes).
>>
>> thanks,
>>
>> Chris
>>
>> On 10/16/18 8:59 PM, Daniil Titov wrote:
>>> Hi Alex, Chris and JC,
>>>
>>> Please review an updated version of the patch that addresses these
>>> issues.
>>>
>>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
>>> Issue:  https://bugs.openjdk.java.net/browse/JDK-8211736
>>>
>>> Thanks!
>>> --Daniil
>>>
>>>
>>> On 10/12/18, 9:52 AM, "Alex Menkov" <***@oracle.com> wrote:
>>>
>>>      Hi Daniil,
>>>      1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL
>>>      2) wrong indent in JdbStopThreadTest.java:
>>>         36         import lib.jdb.JdbCommand;
>>>         37         import lib.jdb.JdbTest;
>>>      3) I think it would be better to make waitForSimplePrompt
>>> property of
>>>      JdbCommand (like JdbCommand.allowExit)
>>>      jdb.command(JdbCommand.run().replyIsSimplePrompt());
>>>      looks much clearer than
>>>      jdb.command(JdbCommand.run(), true);
>>>      4) (TTY.java)
>>>          MessageOutput.lnprint("Breakpoint hit:");
>>>      +  // Print current location and prompt if suspend policy is
>>>      SUSPEND_EVENT_THREAD.
>>>      +  // In case of SUSPEND_ALL policy this is handled by
>>> vmInterrupted()
>>>      method.
>>>      +  if (be.request().suspendPolicy() ==
>>> EventRequest.SUSPEND_EVENT_THREAD) {
>>>      + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
>>>      +      MessageOutput.printPrompt();
>>>      +  }
>>>      We have 3 separate outputs.
>>>      If we have several concurrent threads, we can easy get mess of
>>> outputs
>>>      from different threads.
>>>      I think it would be better to print everything in a single chunk.
>>>      I suppose TTY has other places with similar "non-atomic"
>>> output, so
>>>      maybe revising TTY output should be handled by separate issue.
>>>      --alex
>>>      On 10/11/2018 22:00, Chris Plummer wrote:
>>>      > Hi Daniil,
>>>      >
>>>      > Can you send output from an example jdb session?
>>>      >
>>>      > Do you think maybe we should also call printCurrentLocation()
>>> when the
>>>      > suspend policy is NONE?
>>>      >
>>>      > There's a typo in the following line. The space is on the
>>> wrong side of
>>>      > the comma.
>>>      >
>>>      >    72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
>>> ,bpLine));
>>>      >
>>>      > thanks,
>>>      >
>>>      > Chris
>>>      >
>>>      > On 10/11/18 8:02 PM, Daniil Titov wrote:
>>>      >>
>>>      >> Thank you,  JC!
>>>      >>
>>>      >> Please review an updated version of the patch that fixes
>>> newly added
>>>      >> test for Windows platform  (now it uses system dependent line
>>>      >> separator string).
>>>      >>
>>>      >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
>>>      >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
>>>      >>
>>>      >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>>      >>
>>>      >> Best regards,
>>>      >>
>>>      >> --Daniil
>>>      >>
>>>      >> *From: *JC Beyler <***@google.com>
>>>      >> *Date: *Thursday, October 11, 2018 at 7:17 PM
>>>      >> *To: *<***@oracle.com>
>>>      >> *Cc: *<serviceability-***@openjdk.java.net>
>>>      >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when
>>> breakpoint
>>>      >> is hit and suspend policy is STOP_EVENT_THREAD
>>>      >>
>>>      >> Hi Daniil,
>>>      >>
>>>      >> Looks good to me. I saw a really small nit:
>>>      >>
>>>      >>
>>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
>>>
>>>      >>
>>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
>>>
>>>      >>
>>>      >> 70  jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS
>>> ,bpLine));
>>>      >>
>>>      >> There is a space after the '('.
>>>      >>
>>>      >> No need to send a new webrev for that evidently :),
>>>      >>
>>>      >> Jc
>>>      >>
>>>      >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
>>>      >> <***@oracle.com
>>> <mailto:***@oracle.com>> wrote:
>>>      >>
>>>      >>     Please review the change that fixes the issue with
>>> missing prompt
>>>      >>     in jdb when a breakpoint is hit and the suspend policy
>>> is set to
>>>      >>     stop the thread only.
>>>      >>
>>>      >>     Webrev:
>>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
>>>      >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
>>>      >>     Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>>      >>
>>>      >>     Thanks!
>>>      >>     --Daniil
>>>      >>
>>>      >>
>>>      >>
>>>      >> --
>>>      >>
>>>      >> Thanks,
>>>      >>
>>>      >> Jc
>>>      >>
>>>
Daniil Titov
2018-10-17 23:44:40 UTC
Permalink
On 10/17/18, 3:52 PM, "Chris Plummer" <***@oracle.com> wrote:

What is the jdb state for a breakpoint with SUSPEND_NONE? Can you
actually type in commands even though no threads are suspended?

Chris

On 10/17/18 3:31 PM, Alex Menkov wrote:
> Hi Daniil, Chris,
>
> As far as I understand, the fix does not completely fixes all
> "non-atomic" output issues (at least TTY.executeCommand still prints
> prompt separately), so I agree that handle it as separate issue would
> be better.
> Unfortunately I don't know Gary's ideas for the issue.
>
> About the fix for print prompt:
> 1) TTY.java:
> + // Print current location if suspend policy is SUSPEND_NONE
> I suppose you mean "Print breakpoint location"
>
> 2) Does it make sense to use printCurrentLocation for
> SUSPEND_EVENT_THREAD?
> Is it expected to print something different from printBreakpointLocation?
>
> 3) I don't quite understand why we don't print simple prompt for
> SUSPEND_NONE. IIUC jdb can accept new command in both
> SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb
> waits for next command, right?)
>
> 4) JdbStopThreadTest.java
> New line line in Java regexp is "\\R"
>
> --alex
>
> On 10/17/2018 10:47, Chris Plummer wrote:
>> Hi Alex,
>>
>> I think the tty buffering should be a separate bug fix, and I'd also
>> like input from Gary on it since he had tried something similar at
>> one point. It should probably also include a multithread test to
>> prove the fix is working (after first getting the test to fail
>> without the changes).
>>
>> thanks,
>>
>> Chris
>>
>> On 10/16/18 8:59 PM, Daniil Titov wrote:
>>> Hi Alex, Chris and JC,
>>>
>>> Please review an updated version of the patch that addresses these
>>> issues.
>>>
>>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>>
>>> Thanks!
>>> --Daniil
>>>
>>>
>>> On 10/12/18, 9:52 AM, "Alex Menkov" <***@oracle.com> wrote:
>>>
>>> Hi Daniil,
>>> 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL
>>> 2) wrong indent in JdbStopThreadTest.java:
>>> 36 import lib.jdb.JdbCommand;
>>> 37 import lib.jdb.JdbTest;
>>> 3) I think it would be better to make waitForSimplePrompt
>>> property of
>>> JdbCommand (like JdbCommand.allowExit)
>>> jdb.command(JdbCommand.run().replyIsSimplePrompt());
>>> looks much clearer than
>>> jdb.command(JdbCommand.run(), true);
>>> 4) (TTY.java)
>>> MessageOutput.lnprint("Breakpoint hit:");
>>> + // Print current location and prompt if suspend policy is
>>> SUSPEND_EVENT_THREAD.
>>> + // In case of SUSPEND_ALL policy this is handled by
>>> vmInterrupted()
>>> method.
>>> + if (be.request().suspendPolicy() ==
>>> EventRequest.SUSPEND_EVENT_THREAD) {
>>> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
>>> + MessageOutput.printPrompt();
>>> + }
>>> We have 3 separate outputs.
>>> If we have several concurrent threads, we can easy get mess of
>>> outputs
>>> from different threads.
>>> I think it would be better to print everything in a single chunk.
>>> I suppose TTY has other places with similar "non-atomic"
>>> output, so
>>> maybe revising TTY output should be handled by separate issue.
>>> --alex
>>> On 10/11/2018 22:00, Chris Plummer wrote:
>>> > Hi Daniil,
>>> >
>>> > Can you send output from an example jdb session?
>>> >
>>> > Do you think maybe we should also call printCurrentLocation()
>>> when the
>>> > suspend policy is NONE?
>>> >
>>> > There's a typo in the following line. The space is on the
>>> wrong side of
>>> > the comma.
>>> >
>>> > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
>>> ,bpLine));
>>> >
>>> > thanks,
>>> >
>>> > Chris
>>> >
>>> > On 10/11/18 8:02 PM, Daniil Titov wrote:
>>> >>
>>> >> Thank you, JC!
>>> >>
>>> >> Please review an updated version of the patch that fixes
>>> newly added
>>> >> test for Windows platform (now it uses system dependent line
>>> >> separator string).
>>> >>
>>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
>>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
>>> >>
>>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>> >>
>>> >> Best regards,
>>> >>
>>> >> --Daniil
>>> >>
>>> >> *From: *JC Beyler <***@google.com>
>>> >> *Date: *Thursday, October 11, 2018 at 7:17 PM
>>> >> *To: *<***@oracle.com>
>>> >> *Cc: *<serviceability-***@openjdk.java.net>
>>> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when
>>> breakpoint
>>> >> is hit and suspend policy is STOP_EVENT_THREAD
>>> >>
>>> >> Hi Daniil,
>>> >>
>>> >> Looks good to me. I saw a really small nit:
>>> >>
>>> >>
>>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
>>>
>>> >>
>>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
>>>
>>> >>
>>> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS
>>> ,bpLine));
>>> >>
>>> >> There is a space after the '('.
>>> >>
>>> >> No need to send a new webrev for that evidently :),
>>> >>
>>> >> Jc
>>> >>
>>> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
>>> >> <***@oracle.com
>>> <mailto:***@oracle.com>> wrote:
>>> >>
>>> >> Please review the change that fixes the issue with
>>> missing prompt
>>> >> in jdb when a breakpoint is hit and the suspend policy
>>> is set to
>>> >> stop the thread only.
>>> >>
>>> >> Webrev:
>>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
>>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
>>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>> >>
>>> >> Thanks!
>>> >> --Daniil
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >>
>>> >> Thanks,
>>> >>
>>> >> Jc
>>> >>
>>> >
>>>
>>>
>>
>>
Daniil Titov
2018-10-18 00:06:06 UTC
Permalink
Hi Chris,

The previous email was accidentally fired before I managed to type anything in. Sorry for confusion.

Jdb constantly reads new commands from System.in despite whether the breakpoint is hit and/or the prompt is printed.

cat -n src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java

786 // Process interactive commands.
787 MessageOutput.printPrompt();
788 while (true) {
789 String ln = in.readLine();
790 if (ln == null) {
791 /*
792 * Jdb is being shutdown because debuggee exited, ignore any 'null'
793 * returned by readLine() during shutdown. JDK-8154144.
794 */
795 if (!isShuttingDown()) {
796 MessageOutput.println("Input stream closed.");
797 }
798 ln = "quit";
799 }
800
801 if (ln.startsWith("!!") && lastLine != null) {
802 ln = lastLine + ln.substring(2);
803 MessageOutput.printDirectln(ln);// Special case: use printDirectln()
804 }
805
806 StringTokenizer t = new StringTokenizer(ln);
807 if (t.hasMoreTokens()) {
808 lastLine = ln;
809 executeCommand(t);
810 } else {
811 MessageOutput.printPrompt();
812 }
813 }
814 } catch (VMDisconnectedException e) {
815 handler.handleDisconnectedException();
816 }

Below is a sample debug session for the following test class that sends commands "threads" and "quit"
1 public class LoopTest {
2 public static void main(String[] args) throws Exception {
3 Thread thread = Thread.currentThread();
4 while(true) {
5 print(thread);
6 Thread.sleep(5000);
7 }
8 }
9
10 public static void print(Object obj) {
11 //System.out.println(obj);
12 }
13 }

datitov-mac:work datitov$ ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest
Initializing jdb ...
> stop go at LoopTest:6
Deferring breakpoint LoopTest:6.
It will be set after the class is loaded.
> run
run LoopTest
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
>
VM Started: Set deferred breakpoint LoopTest:6

Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
6 Thread.sleep(5000);

Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
6 Thread.sleep(5000);
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 sleeping
Group InnocuousThreadGroup:
(jdk.internal.misc.InnocuousThread)0x197 Common-Cleaner cond. waiting
>
Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
6 Thread.sleep(5000);

Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
6 Thread.sleep(5000);
quit
Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
6 Thread.sleep(5000);

datitov-mac:work datitov$

I think we could print a simple prompt in this case as Alex suggested.

Best regards,
Daniil

On 10/17/18, 3:52 PM, "Chris Plummer" <***@oracle.com> wrote:

What is the jdb state for a breakpoint with SUSPEND_NONE? Can you
actually type in commands even though no threads are suspended?

Chris

On 10/17/18 3:31 PM, Alex Menkov wrote:
> Hi Daniil, Chris,
>
> As far as I understand, the fix does not completely fixes all
> "non-atomic" output issues (at least TTY.executeCommand still prints
> prompt separately), so I agree that handle it as separate issue would
> be better.
> Unfortunately I don't know Gary's ideas for the issue.
>
> About the fix for print prompt:
> 1) TTY.java:
> + // Print current location if suspend policy is SUSPEND_NONE
> I suppose you mean "Print breakpoint location"
>
> 2) Does it make sense to use printCurrentLocation for
> SUSPEND_EVENT_THREAD?
> Is it expected to print something different from printBreakpointLocation?
>
> 3) I don't quite understand why we don't print simple prompt for
> SUSPEND_NONE. IIUC jdb can accept new command in both
> SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb
> waits for next command, right?)
>
> 4) JdbStopThreadTest.java
> New line line in Java regexp is "\\R"
>
> --alex
>
> On 10/17/2018 10:47, Chris Plummer wrote:
>> Hi Alex,
>>
>> I think the tty buffering should be a separate bug fix, and I'd also
>> like input from Gary on it since he had tried something similar at
>> one point. It should probably also include a multithread test to
>> prove the fix is working (after first getting the test to fail
>> without the changes).
>>
>> thanks,
>>
>> Chris
>>
>> On 10/16/18 8:59 PM, Daniil Titov wrote:
>>> Hi Alex, Chris and JC,
>>>
>>> Please review an updated version of the patch that addresses these
>>> issues.
>>>
>>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>>
>>> Thanks!
>>> --Daniil
>>>
>>>
>>> On 10/12/18, 9:52 AM, "Alex Menkov" <***@oracle.com> wrote:
>>>
>>> Hi Daniil,
>>> 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL
>>> 2) wrong indent in JdbStopThreadTest.java:
>>> 36 import lib.jdb.JdbCommand;
>>> 37 import lib.jdb.JdbTest;
>>> 3) I think it would be better to make waitForSimplePrompt
>>> property of
>>> JdbCommand (like JdbCommand.allowExit)
>>> jdb.command(JdbCommand.run().replyIsSimplePrompt());
>>> looks much clearer than
>>> jdb.command(JdbCommand.run(), true);
>>> 4) (TTY.java)
>>> MessageOutput.lnprint("Breakpoint hit:");
>>> + // Print current location and prompt if suspend policy is
>>> SUSPEND_EVENT_THREAD.
>>> + // In case of SUSPEND_ALL policy this is handled by
>>> vmInterrupted()
>>> method.
>>> + if (be.request().suspendPolicy() ==
>>> EventRequest.SUSPEND_EVENT_THREAD) {
>>> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
>>> + MessageOutput.printPrompt();
>>> + }
>>> We have 3 separate outputs.
>>> If we have several concurrent threads, we can easy get mess of
>>> outputs
>>> from different threads.
>>> I think it would be better to print everything in a single chunk.
>>> I suppose TTY has other places with similar "non-atomic"
>>> output, so
>>> maybe revising TTY output should be handled by separate issue.
>>> --alex
>>> On 10/11/2018 22:00, Chris Plummer wrote:
>>> > Hi Daniil,
>>> >
>>> > Can you send output from an example jdb session?
>>> >
>>> > Do you think maybe we should also call printCurrentLocation()
>>> when the
>>> > suspend policy is NONE?
>>> >
>>> > There's a typo in the following line. The space is on the
>>> wrong side of
>>> > the comma.
>>> >
>>> > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
>>> ,bpLine));
>>> >
>>> > thanks,
>>> >
>>> > Chris
>>> >
>>> > On 10/11/18 8:02 PM, Daniil Titov wrote:
>>> >>
>>> >> Thank you, JC!
>>> >>
>>> >> Please review an updated version of the patch that fixes
>>> newly added
>>> >> test for Windows platform (now it uses system dependent line
>>> >> separator string).
>>> >>
>>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
>>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
>>> >>
>>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>> >>
>>> >> Best regards,
>>> >>
>>> >> --Daniil
>>> >>
>>> >> *From: *JC Beyler <***@google.com>
>>> >> *Date: *Thursday, October 11, 2018 at 7:17 PM
>>> >> *To: *<***@oracle.com>
>>> >> *Cc: *<serviceability-***@openjdk.java.net>
>>> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when
>>> breakpoint
>>> >> is hit and suspend policy is STOP_EVENT_THREAD
>>> >>
>>> >> Hi Daniil,
>>> >>
>>> >> Looks good to me. I saw a really small nit:
>>> >>
>>> >>
>>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
>>>
>>> >>
>>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
>>>
>>> >>
>>> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS
>>> ,bpLine));
>>> >>
>>> >> There is a space after the '('.
>>> >>
>>> >> No need to send a new webrev for that evidently :),
>>> >>
>>> >> Jc
>>> >>
>>> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
>>> >> <***@oracle.com
>>> <mailto:***@oracle.com>> wrote:
>>> >>
>>> >> Please review the change that fixes the issue with
>>> missing prompt
>>> >> in jdb when a breakpoint is hit and the suspend policy
>>> is set to
>>> >> stop the thread only.
>>> >>
>>> >> Webrev:
>>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
>>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
>>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>> >>
>>> >> Thanks!
>>> >> --Daniil
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >>
>>> >> Thanks,
>>> >>
>>> >> Jc
>>> >>
>>> >
>>>
>>>
>>
>>
Daniil Titov
2018-10-18 00:50:47 UTC
Permalink
Hi Chris, Alex and JC,

I created a separate issue to deal with "non-atomic" jdb output at https://bugs.openjdk.java.net/browse/JDK-8212626 .

Please review an updated fix that includes the changes Alex suggested.

Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.04
Issue: https://bugs.openjdk.java.net/browse/JDK-8211736

Thanks!
--Daniil


On 10/17/18, 5:06 PM, "Daniil Titov" <***@oracle.com> wrote:

Hi Chris,

The previous email was accidentally fired before I managed to type anything in. Sorry for confusion.

Jdb constantly reads new commands from System.in despite whether the breakpoint is hit and/or the prompt is printed.

cat -n src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java

786 // Process interactive commands.
787 MessageOutput.printPrompt();
788 while (true) {
789 String ln = in.readLine();
790 if (ln == null) {
791 /*
792 * Jdb is being shutdown because debuggee exited, ignore any 'null'
793 * returned by readLine() during shutdown. JDK-8154144.
794 */
795 if (!isShuttingDown()) {
796 MessageOutput.println("Input stream closed.");
797 }
798 ln = "quit";
799 }
800
801 if (ln.startsWith("!!") && lastLine != null) {
802 ln = lastLine + ln.substring(2);
803 MessageOutput.printDirectln(ln);// Special case: use printDirectln()
804 }
805
806 StringTokenizer t = new StringTokenizer(ln);
807 if (t.hasMoreTokens()) {
808 lastLine = ln;
809 executeCommand(t);
810 } else {
811 MessageOutput.printPrompt();
812 }
813 }
814 } catch (VMDisconnectedException e) {
815 handler.handleDisconnectedException();
816 }

Below is a sample debug session for the following test class that sends commands "threads" and "quit"
1 public class LoopTest {
2 public static void main(String[] args) throws Exception {
3 Thread thread = Thread.currentThread();
4 while(true) {
5 print(thread);
6 Thread.sleep(5000);
7 }
8 }
9
10 public static void print(Object obj) {
11 //System.out.println(obj);
12 }
13 }

datitov-mac:work datitov$ ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest
Initializing jdb ...
> stop go at LoopTest:6
Deferring breakpoint LoopTest:6.
It will be set after the class is loaded.
> run
run LoopTest
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
>
VM Started: Set deferred breakpoint LoopTest:6

Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
6 Thread.sleep(5000);

Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
6 Thread.sleep(5000);
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 sleeping
Group InnocuousThreadGroup:
(jdk.internal.misc.InnocuousThread)0x197 Common-Cleaner cond. waiting
>
Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
6 Thread.sleep(5000);

Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
6 Thread.sleep(5000);
quit
Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
6 Thread.sleep(5000);

datitov-mac:work datitov$

I think we could print a simple prompt in this case as Alex suggested.

Best regards,
Daniil

On 10/17/18, 3:52 PM, "Chris Plummer" <***@oracle.com> wrote:

What is the jdb state for a breakpoint with SUSPEND_NONE? Can you
actually type in commands even though no threads are suspended?

Chris

On 10/17/18 3:31 PM, Alex Menkov wrote:
> Hi Daniil, Chris,
>
> As far as I understand, the fix does not completely fixes all
> "non-atomic" output issues (at least TTY.executeCommand still prints
> prompt separately), so I agree that handle it as separate issue would
> be better.
> Unfortunately I don't know Gary's ideas for the issue.
>
> About the fix for print prompt:
> 1) TTY.java:
> + // Print current location if suspend policy is SUSPEND_NONE
> I suppose you mean "Print breakpoint location"
>
> 2) Does it make sense to use printCurrentLocation for
> SUSPEND_EVENT_THREAD?
> Is it expected to print something different from printBreakpointLocation?
>
> 3) I don't quite understand why we don't print simple prompt for
> SUSPEND_NONE. IIUC jdb can accept new command in both
> SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb
> waits for next command, right?)
>
> 4) JdbStopThreadTest.java
> New line line in Java regexp is "\\R"
>
> --alex
>
> On 10/17/2018 10:47, Chris Plummer wrote:
>> Hi Alex,
>>
>> I think the tty buffering should be a separate bug fix, and I'd also
>> like input from Gary on it since he had tried something similar at
>> one point. It should probably also include a multithread test to
>> prove the fix is working (after first getting the test to fail
>> without the changes).
>>
>> thanks,
>>
>> Chris
>>
>> On 10/16/18 8:59 PM, Daniil Titov wrote:
>>> Hi Alex, Chris and JC,
>>>
>>> Please review an updated version of the patch that addresses these
>>> issues.
>>>
>>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>>
>>> Thanks!
>>> --Daniil
>>>
>>>
>>> On 10/12/18, 9:52 AM, "Alex Menkov" <***@oracle.com> wrote:
>>>
>>> Hi Daniil,
>>> 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL
>>> 2) wrong indent in JdbStopThreadTest.java:
>>> 36 import lib.jdb.JdbCommand;
>>> 37 import lib.jdb.JdbTest;
>>> 3) I think it would be better to make waitForSimplePrompt
>>> property of
>>> JdbCommand (like JdbCommand.allowExit)
>>> jdb.command(JdbCommand.run().replyIsSimplePrompt());
>>> looks much clearer than
>>> jdb.command(JdbCommand.run(), true);
>>> 4) (TTY.java)
>>> MessageOutput.lnprint("Breakpoint hit:");
>>> + // Print current location and prompt if suspend policy is
>>> SUSPEND_EVENT_THREAD.
>>> + // In case of SUSPEND_ALL policy this is handled by
>>> vmInterrupted()
>>> method.
>>> + if (be.request().suspendPolicy() ==
>>> EventRequest.SUSPEND_EVENT_THREAD) {
>>> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
>>> + MessageOutput.printPrompt();
>>> + }
>>> We have 3 separate outputs.
>>> If we have several concurrent threads, we can easy get mess of
>>> outputs
>>> from different threads.
>>> I think it would be better to print everything in a single chunk.
>>> I suppose TTY has other places with similar "non-atomic"
>>> output, so
>>> maybe revising TTY output should be handled by separate issue.
>>> --alex
>>> On 10/11/2018 22:00, Chris Plummer wrote:
>>> > Hi Daniil,
>>> >
>>> > Can you send output from an example jdb session?
>>> >
>>> > Do you think maybe we should also call printCurrentLocation()
>>> when the
>>> > suspend policy is NONE?
>>> >
>>> > There's a typo in the following line. The space is on the
>>> wrong side of
>>> > the comma.
>>> >
>>> > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
>>> ,bpLine));
>>> >
>>> > thanks,
>>> >
>>> > Chris
>>> >
>>> > On 10/11/18 8:02 PM, Daniil Titov wrote:
>>> >>
>>> >> Thank you, JC!
>>> >>
>>> >> Please review an updated version of the patch that fixes
>>> newly added
>>> >> test for Windows platform (now it uses system dependent line
>>> >> separator string).
>>> >>
>>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
>>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
>>> >>
>>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>> >>
>>> >> Best regards,
>>> >>
>>> >> --Daniil
>>> >>
>>> >> *From: *JC Beyler <***@google.com>
>>> >> *Date: *Thursday, October 11, 2018 at 7:17 PM
>>> >> *To: *<***@oracle.com>
>>> >> *Cc: *<serviceability-***@openjdk.java.net>
>>> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when
>>> breakpoint
>>> >> is hit and suspend policy is STOP_EVENT_THREAD
>>> >>
>>> >> Hi Daniil,
>>> >>
>>> >> Looks good to me. I saw a really small nit:
>>> >>
>>> >>
>>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
>>>
>>> >>
>>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
>>>
>>> >>
>>> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS
>>> ,bpLine));
>>> >>
>>> >> There is a space after the '('.
>>> >>
>>> >> No need to send a new webrev for that evidently :),
>>> >>
>>> >> Jc
>>> >>
>>> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
>>> >> <***@oracle.com
>>> <mailto:***@oracle.com>> wrote:
>>> >>
>>> >> Please review the change that fixes the issue with
>>> missing prompt
>>> >> in jdb when a breakpoint is hit and the suspend policy
>>> is set to
>>> >> stop the thread only.
>>> >>
>>> >> Webrev:
>>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
>>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
>>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>> >>
>>> >> Thanks!
>>> >> --Daniil
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >>
>>> >> Thanks,
>>> >>
>>> >> Jc
>>> >>
>>> >
>>>
>>>
>>
>>
JC Beyler
2018-10-18 01:53:09 UTC
Permalink
Hi Daniil,

It looks good to me.

I noticed a tiny nit in TTY.java where you removed an empty line (l171)

Thanks!
Jc


On Wed, Oct 17, 2018 at 5:50 PM Daniil Titov <***@oracle.com>
wrote:

> Hi Chris, Alex and JC,
>
> I created a separate issue to deal with "non-atomic" jdb output at
> https://bugs.openjdk.java.net/browse/JDK-8212626 .
>
> Please review an updated fix that includes the changes Alex suggested.
>
> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.04
> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>
> Thanks!
> --Daniil
>
>
> On 10/17/18, 5:06 PM, "Daniil Titov" <***@oracle.com> wrote:
>
> Hi Chris,
>
> The previous email was accidentally fired before I managed to type
> anything in. Sorry for confusion.
>
> Jdb constantly reads new commands from System.in despite whether the
> breakpoint is hit and/or the prompt is printed.
>
> cat -n
> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
>
> 786 // Process interactive commands.
> 787 MessageOutput.printPrompt();
> 788 while (true) {
> 789 String ln = in.readLine();
> 790 if (ln == null) {
> 791 /*
> 792 * Jdb is being shutdown because
> debuggee exited, ignore any 'null'
> 793 * returned by readLine() during
> shutdown. JDK-8154144.
> 794 */
> 795 if (!isShuttingDown()) {
> 796 MessageOutput.println("Input
> stream closed.");
> 797 }
> 798 ln = "quit";
> 799 }
> 800
> 801 if (ln.startsWith("!!") && lastLine !=
> null) {
> 802 ln = lastLine + ln.substring(2);
> 803 MessageOutput.printDirectln(ln);//
> Special case: use printDirectln()
> 804 }
> 805
> 806 StringTokenizer t = new
> StringTokenizer(ln);
> 807 if (t.hasMoreTokens()) {
> 808 lastLine = ln;
> 809 executeCommand(t);
> 810 } else {
> 811 MessageOutput.printPrompt();
> 812 }
> 813 }
> 814 } catch (VMDisconnectedException e) {
> 815 handler.handleDisconnectedException();
> 816 }
>
> Below is a sample debug session for the following test class that
> sends commands "threads" and "quit"
> 1 public class LoopTest {
> 2 public static void main(String[] args) throws
> Exception {
> 3 Thread thread = Thread.currentThread();
> 4 while(true) {
> 5 print(thread);
> 6 Thread.sleep(5000);
> 7 }
> 8 }
> 9
> 10 public static void print(Object obj) {
> 11 //System.out.println(obj);
> 12 }
> 13 }
>
> datitov-mac:work datitov$
> ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest
> Initializing jdb ...
> > stop go at LoopTest:6
> Deferring breakpoint LoopTest:6.
> It will be set after the class is loaded.
> > run
> run LoopTest
> Set uncaught java.lang.Throwable
> Set deferred uncaught java.lang.Throwable
> >
> VM Started: Set deferred breakpoint LoopTest:6
>
> Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> 6 Thread.sleep(5000);
>
> Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> 6 Thread.sleep(5000);
> 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
> sleeping
> Group InnocuousThreadGroup:
> (jdk.internal.misc.InnocuousThread)0x197 Common-Cleaner
> cond. waiting
> >
> Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> 6 Thread.sleep(5000);
>
> Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> 6 Thread.sleep(5000);
> quit
> Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> 6 Thread.sleep(5000);
>
> datitov-mac:work datitov$
>
> I think we could print a simple prompt in this case as Alex suggested.
>
> Best regards,
> Daniil
>
> On 10/17/18, 3:52 PM, "Chris Plummer" <***@oracle.com>
> wrote:
>
> What is the jdb state for a breakpoint with SUSPEND_NONE? Can you
> actually type in commands even though no threads are suspended?
>
> Chris
>
> On 10/17/18 3:31 PM, Alex Menkov wrote:
> > Hi Daniil, Chris,
> >
> > As far as I understand, the fix does not completely fixes all
> > "non-atomic" output issues (at least TTY.executeCommand still
> prints
> > prompt separately), so I agree that handle it as separate issue
> would
> > be better.
> > Unfortunately I don't know Gary's ideas for the issue.
> >
> > About the fix for print prompt:
> > 1) TTY.java:
> > + // Print current location if suspend policy is
> SUSPEND_NONE
> > I suppose you mean "Print breakpoint location"
> >
> > 2) Does it make sense to use printCurrentLocation for
> > SUSPEND_EVENT_THREAD?
> > Is it expected to print something different from
> printBreakpointLocation?
> >
> > 3) I don't quite understand why we don't print simple prompt for
> > SUSPEND_NONE. IIUC jdb can accept new command in both
> > SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that
> jdb
> > waits for next command, right?)
> >
> > 4) JdbStopThreadTest.java
> > New line line in Java regexp is "\\R"
> >
> > --alex
> >
> > On 10/17/2018 10:47, Chris Plummer wrote:
> >> Hi Alex,
> >>
> >> I think the tty buffering should be a separate bug fix, and I'd
> also
> >> like input from Gary on it since he had tried something similar
> at
> >> one point. It should probably also include a multithread test
> to
> >> prove the fix is working (after first getting the test to fail
> >> without the changes).
> >>
> >> thanks,
> >>
> >> Chris
> >>
> >> On 10/16/18 8:59 PM, Daniil Titov wrote:
> >>> Hi Alex, Chris and JC,
> >>>
> >>> Please review an updated version of the patch that addresses
> these
> >>> issues.
> >>>
> >>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> >>>
> >>> Thanks!
> >>> --Daniil
> >>>
> >>>
> >>> On 10/12/18, 9:52 AM, "Alex Menkov" <***@oracle.com>
> wrote:
> >>>
> >>> Hi Daniil,
> >>> 1) +1 for printCurrentLocation when suspendPolicy !=
> SUSPEND_ALL
> >>> 2) wrong indent in JdbStopThreadTest.java:
> >>> 36 import lib.jdb.JdbCommand;
> >>> 37 import lib.jdb.JdbTest;
> >>> 3) I think it would be better to make waitForSimplePrompt
> >>> property of
> >>> JdbCommand (like JdbCommand.allowExit)
> >>> jdb.command(JdbCommand.run().replyIsSimplePrompt());
> >>> looks much clearer than
> >>> jdb.command(JdbCommand.run(), true);
> >>> 4) (TTY.java)
> >>> MessageOutput.lnprint("Breakpoint hit:");
> >>> + // Print current location and prompt if suspend policy
> is
> >>> SUSPEND_EVENT_THREAD.
> >>> + // In case of SUSPEND_ALL policy this is handled by
> >>> vmInterrupted()
> >>> method.
> >>> + if (be.request().suspendPolicy() ==
> >>> EventRequest.SUSPEND_EVENT_THREAD) {
> >>> +
> printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
> >>> + MessageOutput.printPrompt();
> >>> + }
> >>> We have 3 separate outputs.
> >>> If we have several concurrent threads, we can easy get
> mess of
> >>> outputs
> >>> from different threads.
> >>> I think it would be better to print everything in a
> single chunk.
> >>> I suppose TTY has other places with similar "non-atomic"
> >>> output, so
> >>> maybe revising TTY output should be handled by separate
> issue.
> >>> --alex
> >>> On 10/11/2018 22:00, Chris Plummer wrote:
> >>> > Hi Daniil,
> >>> >
> >>> > Can you send output from an example jdb session?
> >>> >
> >>> > Do you think maybe we should also call
> printCurrentLocation()
> >>> when the
> >>> > suspend policy is NONE?
> >>> >
> >>> > There's a typo in the following line. The space is on
> the
> >>> wrong side of
> >>> > the comma.
> >>> >
> >>> > 72
> jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
> >>> ,bpLine));
> >>> >
> >>> > thanks,
> >>> >
> >>> > Chris
> >>> >
> >>> > On 10/11/18 8:02 PM, Daniil Titov wrote:
> >>> >>
> >>> >> Thank you, JC!
> >>> >>
> >>> >> Please review an updated version of the patch that
> fixes
> >>> newly added
> >>> >> test for Windows platform (now it uses system
> dependent line
> >>> >> separator string).
> >>> >>
> >>> >> Webrev:
> http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
> >>> >> <
> http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
> >>> >>
> >>> >> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8211736
> >>> >>
> >>> >> Best regards,
> >>> >>
> >>> >> --Daniil
> >>> >>
> >>> >> *From: *JC Beyler <***@google.com>
> >>> >> *Date: *Thursday, October 11, 2018 at 7:17 PM
> >>> >> *To: *<***@oracle.com>
> >>> >> *Cc: *<serviceability-***@openjdk.java.net>
> >>> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt
> when
> >>> breakpoint
> >>> >> is hit and suspend policy is STOP_EVENT_THREAD
> >>> >>
> >>> >> Hi Daniil,
> >>> >>
> >>> >> Looks good to me. I saw a really small nit:
> >>> >>
> >>> >>
> >>>
> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
> >>>
> >>> >>
> >>> <
> http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
>
> >>>
> >>> >>
> >>> >> 70 jdb.command(JdbCommand.stopThreadAt(
> DEBUGGEE_CLASS
> >>> ,bpLine));
> >>> >>
> >>> >> There is a space after the '('.
> >>> >>
> >>> >> No need to send a new webrev for that evidently :),
> >>> >>
> >>> >> Jc
> >>> >>
> >>> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
> >>> >> <***@oracle.com
> >>> <mailto:***@oracle.com>> wrote:
> >>> >>
> >>> >> Please review the change that fixes the issue with
> >>> missing prompt
> >>> >> in jdb when a breakpoint is hit and the suspend
> policy
> >>> is set to
> >>> >> stop the thread only.
> >>> >>
> >>> >> Webrev:
> >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
> >>> >> <
> http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
> >>> >> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8211736
> >>> >>
> >>> >> Thanks!
> >>> >> --Daniil
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >>
> >>> >> Thanks,
> >>> >>
> >>> >> Jc
> >>> >>
> >>> >
> >>>
> >>>
> >>
> >>
>
>
>
>
>
>

--

Thanks,
Jc
Alex Menkov
2018-10-18 17:40:00 UTC
Permalink
+1

--alex

On 10/17/2018 18:53, JC Beyler wrote:
> Hi Daniil,
>
> It looks good to me.
>
> I noticed a tiny nit in TTY.java where you removed an empty line (l171)
>
> Thanks!
> Jc
>
>
> On Wed, Oct 17, 2018 at 5:50 PM Daniil Titov <***@oracle.com
> <mailto:***@oracle.com>> wrote:
>
> Hi Chris, Alex and JC,
>
> I created a separate issue to deal with "non-atomic" jdb output at
> https://bugs.openjdk.java.net/browse/JDK-8212626 .
>
> Please review an updated fix that includes the changes Alex suggested.
>
> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.04
> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.04>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>
> Thanks!
> --Daniil
>
>
> On 10/17/18, 5:06 PM, "Daniil Titov" <***@oracle.com
> <mailto:***@oracle.com>> wrote:
>
>     Hi Chris,
>
>     The previous email was accidentally fired before I managed to
> type anything in. Sorry for confusion.
>
>     Jdb constantly reads new commands from System.in despite
> whether the breakpoint is hit and/or the prompt is printed.
>
>     cat -n
> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
>
>     786             // Process interactive commands.
>        787                  MessageOutput.printPrompt();
>        788                  while (true) {
>        789                      String ln = in.readLine();
>        790                      if (ln == null) {
>        791                          /*
>        792                           *  Jdb is being shutdown
> because debuggee exited, ignore any 'null'
>        793                           *  returned by readLine()
> during shutdown. JDK-8154144.
>        794                           */
>        795                          if (!isShuttingDown()) {
>        796
> MessageOutput.println("Input stream closed.");
>        797                          }
>        798                          ln = "quit";
>        799                      }
>        800
>        801                      if (ln.startsWith("!!") && lastLine
> != null) {
>        802                          ln = lastLine + ln.substring(2);
>        803
> MessageOutput.printDirectln(ln);// Special case: use printDirectln()
>        804                      }
>        805
>        806                      StringTokenizer t = new
> StringTokenizer(ln);
>        807                      if (t.hasMoreTokens()) {
>        808                          lastLine = ln;
>        809                          executeCommand(t);
>        810                      } else {
>        811                          MessageOutput.printPrompt();
>        812                      }
>        813                  }
>        814              } catch (VMDisconnectedException e) {
>        815                  handler.handleDisconnectedException();
>        816              }
>
>     Below is a sample debug session for the following test class
> that sends commands "threads" and "quit"
>     1   public class LoopTest {
>          2          public static void main(String[] args) throws
> Exception {
>          3              Thread thread = Thread.currentThread();
>          4              while(true) {
>          5                  print(thread);
>          6                  Thread.sleep(5000);
>          7              }
>          8          }
>          9
>         10          public static void print(Object obj) {
>         11              //System.out.println(obj);
>         12          }
>         13      }
>
>     datitov-mac:work datitov$
> ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest
>     Initializing jdb ...
>     > stop go at LoopTest:6
>     Deferring breakpoint LoopTest:6.
>     It will be set after the class is loaded.
>     > run
>     run LoopTest
>     Set uncaught java.lang.Throwable
>     Set deferred uncaught java.lang.Throwable
>     >
>     VM Started: Set deferred breakpoint LoopTest:6
>
>     Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
>     6                Thread.sleep(5000);
>
>     Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
>     6                Thread.sleep(5000);
>     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
>     sleeping
>     Group InnocuousThreadGroup:
>       (jdk.internal.misc.InnocuousThread)0x197
> Common-Cleaner    cond. waiting
>     >
>     Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
>     6                Thread.sleep(5000);
>
>     Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
>     6                Thread.sleep(5000);
>     quit
>     Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
>     6                Thread.sleep(5000);
>
>     datitov-mac:work datitov$
>
>     I think we could print a simple prompt in this case as Alex
> suggested.
>
>     Best regards,
>     Daniil
>
>     On 10/17/18, 3:52 PM, "Chris Plummer"
> <***@oracle.com <mailto:***@oracle.com>> wrote:
>
>         What is the jdb state for a breakpoint with SUSPEND_NONE?
> Can you
>         actually type in commands even though no threads are suspended?
>
>         Chris
>
>         On 10/17/18 3:31 PM, Alex Menkov wrote:
>         > Hi Daniil, Chris,
>         >
>         > As far as I understand, the fix does not completely fixes
> all
>         > "non-atomic" output issues (at least TTY.executeCommand
> still prints
>         > prompt separately), so I agree that handle it as separate
> issue would
>         > be better.
>         > Unfortunately I don't know Gary's ideas for the issue.
>         >
>         > About the fix for print prompt:
>         > 1) TTY.java:
>         > +            // Print current location if suspend policy
> is SUSPEND_NONE
>         > I suppose you mean "Print breakpoint location"
>         >
>         > 2) Does it make sense to use printCurrentLocation for
>         > SUSPEND_EVENT_THREAD?
>         > Is it expected to print something different from
> printBreakpointLocation?
>         >
>         > 3) I don't quite understand why we don't print simple
> prompt for
>         > SUSPEND_NONE. IIUC jdb can accept new command in both
>         > SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows
> that jdb
>         > waits for next command, right?)
>         >
>         > 4) JdbStopThreadTest.java
>         > New line line in Java regexp is "\\R"
>         >
>         > --alex
>         >
>         > On 10/17/2018 10:47, Chris Plummer wrote:
>         >> Hi Alex,
>         >>
>         >> I think the tty buffering should be a separate bug fix,
> and I'd also
>         >> like input from Gary on it since he had tried something
> similar at
>         >> one point. It should probably also include a multithread
> test to
>         >> prove the fix is working (after first getting the test
> to fail
>         >> without the changes).
>         >>
>         >> thanks,
>         >>
>         >> Chris
>         >>
>         >> On 10/16/18 8:59 PM, Daniil Titov wrote:
>         >>> Hi Alex, Chris and JC,
>         >>>
>         >>> Please review an updated version of the patch that
> addresses these
>         >>> issues.
>         >>>
>         >>> Webrev:
> http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.03/>
>         >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>         >>>
>         >>> Thanks!
>         >>> --Daniil
>         >>>
>         >>>
>         >>> On 10/12/18, 9:52 AM, "Alex Menkov"
> <***@oracle.com <mailto:***@oracle.com>> wrote:
>         >>>
>         >>>      Hi Daniil,
>         >>>      1) +1 for printCurrentLocation when suspendPolicy
> != SUSPEND_ALL
>         >>>      2) wrong indent in JdbStopThreadTest.java:
>         >>>         36         import lib.jdb.JdbCommand;
>         >>>         37         import lib.jdb.JdbTest;
>         >>>      3) I think it would be better to make
> waitForSimplePrompt
>         >>> property of
>         >>>      JdbCommand (like JdbCommand.allowExit)
>         >>>      jdb.command(JdbCommand.run().replyIsSimplePrompt());
>         >>>      looks much clearer than
>         >>>      jdb.command(JdbCommand.run(), true);
>         >>>      4) (TTY.java)
>         >>>          MessageOutput.lnprint("Breakpoint hit:");
>         >>>      +  // Print current location and prompt if suspend
> policy is
>         >>>      SUSPEND_EVENT_THREAD.
>         >>>      +  // In case of SUSPEND_ALL policy this is
> handled by
>         >>> vmInterrupted()
>         >>>      method.
>         >>>      +  if (be.request().suspendPolicy() ==
>         >>> EventRequest.SUSPEND_EVENT_THREAD) {
>         >>>      +
> printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
>         >>>      +      MessageOutput.printPrompt();
>         >>>      +  }
>         >>>      We have 3 separate outputs.
>         >>>      If we have several concurrent threads, we can easy
> get mess of
>         >>> outputs
>         >>>      from different threads.
>         >>>      I think it would be better to print everything in
> a single chunk.
>         >>>      I suppose TTY has other places with similar
> "non-atomic"
>         >>> output, so
>         >>>      maybe revising TTY output should be handled by
> separate issue.
>         >>>      --alex
>         >>>      On 10/11/2018 22:00, Chris Plummer wrote:
>         >>>      > Hi Daniil,
>         >>>      >
>         >>>      > Can you send output from an example jdb session?
>         >>>      >
>         >>>      > Do you think maybe we should also call
> printCurrentLocation()
>         >>> when the
>         >>>      > suspend policy is NONE?
>         >>>      >
>         >>>      > There's a typo in the following line. The space
> is on the
>         >>> wrong side of
>         >>>      > the comma.
>         >>>      >
>         >>>      >    72
> jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
>         >>> ,bpLine));
>         >>>      >
>         >>>      > thanks,
>         >>>      >
>         >>>      > Chris
>         >>>      >
>         >>>      > On 10/11/18 8:02 PM, Daniil Titov wrote:
>         >>>      >>
>         >>>      >> Thank you,  JC!
>         >>>      >>
>         >>>      >> Please review an updated version of the patch
> that fixes
>         >>> newly added
>         >>>      >> test for Windows platform  (now it uses system
> dependent line
>         >>>      >> separator string).
>         >>>      >>
>         >>>      >>
> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
>         >>>      >>
> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
>         >>>      >>
>         >>>      >> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8211736
>         >>>      >>
>         >>>      >> Best regards,
>         >>>      >>
>         >>>      >> --Daniil
>         >>>      >>
>         >>>      >> *From: *JC Beyler <***@google.com
> <mailto:***@google.com>>
>         >>>      >> *Date: *Thursday, October 11, 2018 at 7:17 PM
>         >>>      >> *To: *<***@oracle.com
> <mailto:***@oracle.com>>
>         >>>      >> *Cc: *<serviceability-***@openjdk.java.net
> <mailto:serviceability-***@openjdk.java.net>>
>         >>>      >> *Subject: *Re: RFR 8211736: jdb doesn't print
> prompt when
>         >>> breakpoint
>         >>>      >> is hit and suspend policy is STOP_EVENT_THREAD
>         >>>      >>
>         >>>      >> Hi Daniil,
>         >>>      >>
>         >>>      >> Looks good to me. I saw a really small nit:
>         >>>      >>
>         >>>      >>
>         >>>
> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
>
>         >>>
>         >>>      >>
>         >>>
> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
>
>         >>>
>         >>>      >>
>         >>>      >> 70  jdb.command(JdbCommand.stopThreadAt(
> DEBUGGEE_CLASS
>         >>> ,bpLine));
>         >>>      >>
>         >>>      >> There is a space after the '('.
>         >>>      >>
>         >>>      >> No need to send a new webrev for that evidently :),
>         >>>      >>
>         >>>      >> Jc
>         >>>      >>
>         >>>      >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
>         >>>      >> <***@oracle.com
> <mailto:***@oracle.com>
>         >>> <mailto:***@oracle.com
> <mailto:***@oracle.com>>> wrote:
>         >>>      >>
>         >>>      >>     Please review the change that fixes the
> issue with
>         >>> missing prompt
>         >>>      >>     in jdb when a breakpoint is hit and the
> suspend policy
>         >>> is set to
>         >>>      >>     stop the thread only.
>         >>>      >>
>         >>>      >>     Webrev:
>         >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
>         >>>      >>
> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
>         >>>      >>     Issue:
> https://bugs.openjdk.java.net/browse/JDK-8211736
>         >>>      >>
>         >>>      >>     Thanks!
>         >>>      >>     --Daniil
>         >>>      >>
>         >>>      >>
>         >>>      >>
>         >>>      >> --
>         >>>      >>
>         >>>      >> Thanks,
>         >>>      >>
>         >>>      >> Jc
>         >>>      >>
>         >>>      >
>         >>>
>         >>>
>         >>
>         >>
>
>
>
>
>
>
>
Gary Adams
2018-10-18 11:12:26 UTC
Permalink
I'm not certain that we should be printing locations or prompts for
events when the vm has not been suspended. This looks OK for the
simple test case we are working on here, but in real life there may
be a lot more output produced.

The user has to select a specific thread before additional commands
can be performed in the correct context. e.g. threads, thread n, where, ...
So the information is available to the user. It doesn't have to be
produced at the time the event is processed.

I'm uncomfortable putting too much trust in waiting for the simple prompt,
because there is too great a chance of false positives on such a small
marker.


On 10/17/18, 8:50 PM, Daniil Titov wrote:
> Hi Chris, Alex and JC,
>
> I created a separate issue to deal with "non-atomic" jdb output at https://bugs.openjdk.java.net/browse/JDK-8212626 .
>
> Please review an updated fix that includes the changes Alex suggested.
>
> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.04
> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>
> Thanks!
> --Daniil
>
>
> On 10/17/18, 5:06 PM, "Daniil Titov"<***@oracle.com> wrote:
>
> Hi Chris,
>
> The previous email was accidentally fired before I managed to type anything in. Sorry for confusion.
>
> Jdb constantly reads new commands from System.in despite whether the breakpoint is hit and/or the prompt is printed.
>
> cat -n src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
>
> 786 // Process interactive commands.
> 787 MessageOutput.printPrompt();
> 788 while (true) {
> 789 String ln = in.readLine();
> 790 if (ln == null) {
> 791 /*
> 792 * Jdb is being shutdown because debuggee exited, ignore any 'null'
> 793 * returned by readLine() during shutdown. JDK-8154144.
> 794 */
> 795 if (!isShuttingDown()) {
> 796 MessageOutput.println("Input stream closed.");
> 797 }
> 798 ln = "quit";
> 799 }
> 800
> 801 if (ln.startsWith("!!")&& lastLine != null) {
> 802 ln = lastLine + ln.substring(2);
> 803 MessageOutput.printDirectln(ln);// Special case: use printDirectln()
> 804 }
> 805
> 806 StringTokenizer t = new StringTokenizer(ln);
> 807 if (t.hasMoreTokens()) {
> 808 lastLine = ln;
> 809 executeCommand(t);
> 810 } else {
> 811 MessageOutput.printPrompt();
> 812 }
> 813 }
> 814 } catch (VMDisconnectedException e) {
> 815 handler.handleDisconnectedException();
> 816 }
>
> Below is a sample debug session for the following test class that sends commands "threads" and "quit"
> 1 public class LoopTest {
> 2 public static void main(String[] args) throws Exception {
> 3 Thread thread = Thread.currentThread();
> 4 while(true) {
> 5 print(thread);
> 6 Thread.sleep(5000);
> 7 }
> 8 }
> 9
> 10 public static void print(Object obj) {
> 11 //System.out.println(obj);
> 12 }
> 13 }
>
> datitov-mac:work datitov$ ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest
> Initializing jdb ...
> > stop go at LoopTest:6
> Deferring breakpoint LoopTest:6.
> It will be set after the class is loaded.
> > run
> run LoopTest
> Set uncaught java.lang.Throwable
> Set deferred uncaught java.lang.Throwable
> >
> VM Started: Set deferred breakpoint LoopTest:6
>
> Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> 6 Thread.sleep(5000);
>
> Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> 6 Thread.sleep(5000);
> 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 sleeping
> Group InnocuousThreadGroup:
> (jdk.internal.misc.InnocuousThread)0x197 Common-Cleaner cond. waiting
> >
> Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> 6 Thread.sleep(5000);
>
> Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> 6 Thread.sleep(5000);
> quit
> Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> 6 Thread.sleep(5000);
>
> datitov-mac:work datitov$
>
> I think we could print a simple prompt in this case as Alex suggested.
>
> Best regards,
> Daniil
>
> On 10/17/18, 3:52 PM, "Chris Plummer"<***@oracle.com> wrote:
>
> What is the jdb state for a breakpoint with SUSPEND_NONE? Can you
> actually type in commands even though no threads are suspended?
>
> Chris
>
> On 10/17/18 3:31 PM, Alex Menkov wrote:
> > Hi Daniil, Chris,
> >
> > As far as I understand, the fix does not completely fixes all
> > "non-atomic" output issues (at least TTY.executeCommand still prints
> > prompt separately), so I agree that handle it as separate issue would
> > be better.
> > Unfortunately I don't know Gary's ideas for the issue.
> >
> > About the fix for print prompt:
> > 1) TTY.java:
> > + // Print current location if suspend policy is SUSPEND_NONE
> > I suppose you mean "Print breakpoint location"
> >
> > 2) Does it make sense to use printCurrentLocation for
> > SUSPEND_EVENT_THREAD?
> > Is it expected to print something different from printBreakpointLocation?
> >
> > 3) I don't quite understand why we don't print simple prompt for
> > SUSPEND_NONE. IIUC jdb can accept new command in both
> > SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb
> > waits for next command, right?)
> >
> > 4) JdbStopThreadTest.java
> > New line line in Java regexp is "\\R"
> >
> > --alex
> >
> > On 10/17/2018 10:47, Chris Plummer wrote:
> >> Hi Alex,
> >>
> >> I think the tty buffering should be a separate bug fix, and I'd also
> >> like input from Gary on it since he had tried something similar at
> >> one point. It should probably also include a multithread test to
> >> prove the fix is working (after first getting the test to fail
> >> without the changes).
> >>
> >> thanks,
> >>
> >> Chris
> >>
> >> On 10/16/18 8:59 PM, Daniil Titov wrote:
> >>> Hi Alex, Chris and JC,
> >>>
> >>> Please review an updated version of the patch that addresses these
> >>> issues.
> >>>
> >>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> >>>
> >>> Thanks!
> >>> --Daniil
> >>>
> >>>
> >>> On 10/12/18, 9:52 AM, "Alex Menkov"<***@oracle.com> wrote:
> >>>
> >>> Hi Daniil,
> >>> 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL
> >>> 2) wrong indent in JdbStopThreadTest.java:
> >>> 36 import lib.jdb.JdbCommand;
> >>> 37 import lib.jdb.JdbTest;
> >>> 3) I think it would be better to make waitForSimplePrompt
> >>> property of
> >>> JdbCommand (like JdbCommand.allowExit)
> >>> jdb.command(JdbCommand.run().replyIsSimplePrompt());
> >>> looks much clearer than
> >>> jdb.command(JdbCommand.run(), true);
> >>> 4) (TTY.java)
> >>> MessageOutput.lnprint("Breakpoint hit:");
> >>> + // Print current location and prompt if suspend policy is
> >>> SUSPEND_EVENT_THREAD.
> >>> + // In case of SUSPEND_ALL policy this is handled by
> >>> vmInterrupted()
> >>> method.
> >>> + if (be.request().suspendPolicy() ==
> >>> EventRequest.SUSPEND_EVENT_THREAD) {
> >>> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
> >>> + MessageOutput.printPrompt();
> >>> + }
> >>> We have 3 separate outputs.
> >>> If we have several concurrent threads, we can easy get mess of
> >>> outputs
> >>> from different threads.
> >>> I think it would be better to print everything in a single chunk.
> >>> I suppose TTY has other places with similar "non-atomic"
> >>> output, so
> >>> maybe revising TTY output should be handled by separate issue.
> >>> --alex
> >>> On 10/11/2018 22:00, Chris Plummer wrote:
> >>> > Hi Daniil,
> >>> >
> >>> > Can you send output from an example jdb session?
> >>> >
> >>> > Do you think maybe we should also call printCurrentLocation()
> >>> when the
> >>> > suspend policy is NONE?
> >>> >
> >>> > There's a typo in the following line. The space is on the
> >>> wrong side of
> >>> > the comma.
> >>> >
> >>> > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
> >>> ,bpLine));
> >>> >
> >>> > thanks,
> >>> >
> >>> > Chris
> >>> >
> >>> > On 10/11/18 8:02 PM, Daniil Titov wrote:
> >>> >>
> >>> >> Thank you, JC!
> >>> >>
> >>> >> Please review an updated version of the patch that fixes
> >>> newly added
> >>> >> test for Windows platform (now it uses system dependent line
> >>> >> separator string).
> >>> >>
> >>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
> >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
> >>> >>
> >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> >>> >>
> >>> >> Best regards,
> >>> >>
> >>> >> --Daniil
> >>> >>
> >>> >> *From: *JC Beyler<***@google.com>
> >>> >> *Date: *Thursday, October 11, 2018 at 7:17 PM
> >>> >> *To: *<***@oracle.com>
> >>> >> *Cc: *<serviceability-***@openjdk.java.net>
> >>> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when
> >>> breakpoint
> >>> >> is hit and suspend policy is STOP_EVENT_THREAD
> >>> >>
> >>> >> Hi Daniil,
> >>> >>
> >>> >> Looks good to me. I saw a really small nit:
> >>> >>
> >>> >>
> >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
> >>>
> >>> >>
> >>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
> >>>
> >>> >>
> >>> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS
> >>> ,bpLine));
> >>> >>
> >>> >> There is a space after the '('.
> >>> >>
> >>> >> No need to send a new webrev for that evidently :),
> >>> >>
> >>> >> Jc
> >>> >>
> >>> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
> >>> >> <***@oracle.com
> >>> <mailto:***@oracle.com>> wrote:
> >>> >>
> >>> >> Please review the change that fixes the issue with
> >>> missing prompt
> >>> >> in jdb when a breakpoint is hit and the suspend policy
> >>> is set to
> >>> >> stop the thread only.
> >>> >>
> >>> >> Webrev:
> >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
> >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
> >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> >>> >>
> >>> >> Thanks!
> >>> >> --Daniil
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >>
> >>> >> Thanks,
> >>> >>
> >>> >> Jc
> >>> >>
> >>> >
> >>>
> >>>
> >>
> >>
>
>
>
>
>
Daniil Titov
2018-10-18 15:53:41 UTC
Permalink
Hi Gary,

Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach?

Thanks!

Best regards,
Daniil



On 10/18/18, 4:09 AM, "Gary Adams" <***@oracle.com> wrote:

I'm not certain that we should be printing locations or prompts for
events when the vm has not been suspended. This looks OK for the
simple test case we are working on here, but in real life there may
be a lot more output produced.

The user has to select a specific thread before additional commands
can be performed in the correct context. e.g. threads, thread n, where, ...
So the information is available to the user. It doesn't have to be
produced at the time the event is processed.

I'm uncomfortable putting too much trust in waiting for the simple prompt,
because there is too great a chance of false positives on such a small
marker.


On 10/17/18, 8:50 PM, Daniil Titov wrote:
> Hi Chris, Alex and JC,
>
> I created a separate issue to deal with "non-atomic" jdb output at https://bugs.openjdk.java.net/browse/JDK-8212626 .
>
> Please review an updated fix that includes the changes Alex suggested.
>
> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.04
> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>
> Thanks!
> --Daniil
>
>
> On 10/17/18, 5:06 PM, "Daniil Titov"<***@oracle.com> wrote:
>
> Hi Chris,
>
> The previous email was accidentally fired before I managed to type anything in. Sorry for confusion.
>
> Jdb constantly reads new commands from System.in despite whether the breakpoint is hit and/or the prompt is printed.
>
> cat -n src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
>
> 786 // Process interactive commands.
> 787 MessageOutput.printPrompt();
> 788 while (true) {
> 789 String ln = in.readLine();
> 790 if (ln == null) {
> 791 /*
> 792 * Jdb is being shutdown because debuggee exited, ignore any 'null'
> 793 * returned by readLine() during shutdown. JDK-8154144.
> 794 */
> 795 if (!isShuttingDown()) {
> 796 MessageOutput.println("Input stream closed.");
> 797 }
> 798 ln = "quit";
> 799 }
> 800
> 801 if (ln.startsWith("!!")&& lastLine != null) {
> 802 ln = lastLine + ln.substring(2);
> 803 MessageOutput.printDirectln(ln);// Special case: use printDirectln()
> 804 }
> 805
> 806 StringTokenizer t = new StringTokenizer(ln);
> 807 if (t.hasMoreTokens()) {
> 808 lastLine = ln;
> 809 executeCommand(t);
> 810 } else {
> 811 MessageOutput.printPrompt();
> 812 }
> 813 }
> 814 } catch (VMDisconnectedException e) {
> 815 handler.handleDisconnectedException();
> 816 }
>
> Below is a sample debug session for the following test class that sends commands "threads" and "quit"
> 1 public class LoopTest {
> 2 public static void main(String[] args) throws Exception {
> 3 Thread thread = Thread.currentThread();
> 4 while(true) {
> 5 print(thread);
> 6 Thread.sleep(5000);
> 7 }
> 8 }
> 9
> 10 public static void print(Object obj) {
> 11 //System.out.println(obj);
> 12 }
> 13 }
>
> datitov-mac:work datitov$ ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest
> Initializing jdb ...
> > stop go at LoopTest:6
> Deferring breakpoint LoopTest:6.
> It will be set after the class is loaded.
> > run
> run LoopTest
> Set uncaught java.lang.Throwable
> Set deferred uncaught java.lang.Throwable
> >
> VM Started: Set deferred breakpoint LoopTest:6
>
> Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> 6 Thread.sleep(5000);
>
> Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> 6 Thread.sleep(5000);
> 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 sleeping
> Group InnocuousThreadGroup:
> (jdk.internal.misc.InnocuousThread)0x197 Common-Cleaner cond. waiting
> >
> Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> 6 Thread.sleep(5000);
>
> Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> 6 Thread.sleep(5000);
> quit
> Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> 6 Thread.sleep(5000);
>
> datitov-mac:work datitov$
>
> I think we could print a simple prompt in this case as Alex suggested.
>
> Best regards,
> Daniil
>
> On 10/17/18, 3:52 PM, "Chris Plummer"<***@oracle.com> wrote:
>
> What is the jdb state for a breakpoint with SUSPEND_NONE? Can you
> actually type in commands even though no threads are suspended?
>
> Chris
>
> On 10/17/18 3:31 PM, Alex Menkov wrote:
> > Hi Daniil, Chris,
> >
> > As far as I understand, the fix does not completely fixes all
> > "non-atomic" output issues (at least TTY.executeCommand still prints
> > prompt separately), so I agree that handle it as separate issue would
> > be better.
> > Unfortunately I don't know Gary's ideas for the issue.
> >
> > About the fix for print prompt:
> > 1) TTY.java:
> > + // Print current location if suspend policy is SUSPEND_NONE
> > I suppose you mean "Print breakpoint location"
> >
> > 2) Does it make sense to use printCurrentLocation for
> > SUSPEND_EVENT_THREAD?
> > Is it expected to print something different from printBreakpointLocation?
> >
> > 3) I don't quite understand why we don't print simple prompt for
> > SUSPEND_NONE. IIUC jdb can accept new command in both
> > SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb
> > waits for next command, right?)
> >
> > 4) JdbStopThreadTest.java
> > New line line in Java regexp is "\\R"
> >
> > --alex
> >
> > On 10/17/2018 10:47, Chris Plummer wrote:
> >> Hi Alex,
> >>
> >> I think the tty buffering should be a separate bug fix, and I'd also
> >> like input from Gary on it since he had tried something similar at
> >> one point. It should probably also include a multithread test to
> >> prove the fix is working (after first getting the test to fail
> >> without the changes).
> >>
> >> thanks,
> >>
> >> Chris
> >>
> >> On 10/16/18 8:59 PM, Daniil Titov wrote:
> >>> Hi Alex, Chris and JC,
> >>>
> >>> Please review an updated version of the patch that addresses these
> >>> issues.
> >>>
> >>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> >>>
> >>> Thanks!
> >>> --Daniil
> >>>
> >>>
> >>> On 10/12/18, 9:52 AM, "Alex Menkov"<***@oracle.com> wrote:
> >>>
> >>> Hi Daniil,
> >>> 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL
> >>> 2) wrong indent in JdbStopThreadTest.java:
> >>> 36 import lib.jdb.JdbCommand;
> >>> 37 import lib.jdb.JdbTest;
> >>> 3) I think it would be better to make waitForSimplePrompt
> >>> property of
> >>> JdbCommand (like JdbCommand.allowExit)
> >>> jdb.command(JdbCommand.run().replyIsSimplePrompt());
> >>> looks much clearer than
> >>> jdb.command(JdbCommand.run(), true);
> >>> 4) (TTY.java)
> >>> MessageOutput.lnprint("Breakpoint hit:");
> >>> + // Print current location and prompt if suspend policy is
> >>> SUSPEND_EVENT_THREAD.
> >>> + // In case of SUSPEND_ALL policy this is handled by
> >>> vmInterrupted()
> >>> method.
> >>> + if (be.request().suspendPolicy() ==
> >>> EventRequest.SUSPEND_EVENT_THREAD) {
> >>> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
> >>> + MessageOutput.printPrompt();
> >>> + }
> >>> We have 3 separate outputs.
> >>> If we have several concurrent threads, we can easy get mess of
> >>> outputs
> >>> from different threads.
> >>> I think it would be better to print everything in a single chunk.
> >>> I suppose TTY has other places with similar "non-atomic"
> >>> output, so
> >>> maybe revising TTY output should be handled by separate issue.
> >>> --alex
> >>> On 10/11/2018 22:00, Chris Plummer wrote:
> >>> > Hi Daniil,
> >>> >
> >>> > Can you send output from an example jdb session?
> >>> >
> >>> > Do you think maybe we should also call printCurrentLocation()
> >>> when the
> >>> > suspend policy is NONE?
> >>> >
> >>> > There's a typo in the following line. The space is on the
> >>> wrong side of
> >>> > the comma.
> >>> >
> >>> > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
> >>> ,bpLine));
> >>> >
> >>> > thanks,
> >>> >
> >>> > Chris
> >>> >
> >>> > On 10/11/18 8:02 PM, Daniil Titov wrote:
> >>> >>
> >>> >> Thank you, JC!
> >>> >>
> >>> >> Please review an updated version of the patch that fixes
> >>> newly added
> >>> >> test for Windows platform (now it uses system dependent line
> >>> >> separator string).
> >>> >>
> >>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
> >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
> >>> >>
> >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> >>> >>
> >>> >> Best regards,
> >>> >>
> >>> >> --Daniil
> >>> >>
> >>> >> *From: *JC Beyler<***@google.com>
> >>> >> *Date: *Thursday, October 11, 2018 at 7:17 PM
> >>> >> *To: *<***@oracle.com>
> >>> >> *Cc: *<serviceability-***@openjdk.java.net>
> >>> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when
> >>> breakpoint
> >>> >> is hit and suspend policy is STOP_EVENT_THREAD
> >>> >>
> >>> >> Hi Daniil,
> >>> >>
> >>> >> Looks good to me. I saw a really small nit:
> >>> >>
> >>> >>
> >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
> >>>
> >>> >>
> >>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
> >>>
> >>> >>
> >>> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS
> >>> ,bpLine));
> >>> >>
> >>> >> There is a space after the '('.
> >>> >>
> >>> >> No need to send a new webrev for that evidently :),
> >>> >>
> >>> >> Jc
> >>> >>
> >>> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
> >>> >> <***@oracle.com
> >>> <mailto:***@oracle.com>> wrote:
> >>> >>
> >>> >> Please review the change that fixes the issue with
> >>> missing prompt
> >>> >> in jdb when a breakpoint is hit and the suspend policy
> >>> is set to
> >>> >> stop the thread only.
> >>> >>
> >>> >> Webrev:
> >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
> >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
> >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> >>> >>
> >>> >> Thanks!
> >>> >> --Daniil
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >>
> >>> >> Thanks,
> >>> >>
> >>> >> Jc
> >>> >>
> >>> >
> >>>
> >>>
> >>
> >>
>
>
>
>
>
g***@oracle.com
2018-10-19 07:54:43 UTC
Permalink
It's not clear to me if the omitted location information for the non
stopping
cases was intentional or not. It may be sufficient to know that the
event fired
without the extra information.

I don't think a settable prompt is required either. There are plenty of
jdb commands that
could be used with the wait for message in tests that need to
synchronize at a specific
point in the test sequence.

I don't think we see wait for simple prompt in any of the tests, because it
is not reliable enough.

On 10/18/18 11:53 AM, Daniil Titov wrote:
> Hi Gary,
>
> Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach?
>
> Thanks!
>
> Best regards,
> Daniil
>
>
>
> On 10/18/18, 4:09 AM, "Gary Adams" <***@oracle.com> wrote:
>
> I'm not certain that we should be printing locations or prompts for
> events when the vm has not been suspended. This looks OK for the
> simple test case we are working on here, but in real life there may
> be a lot more output produced.
>
> The user has to select a specific thread before additional commands
> can be performed in the correct context. e.g. threads, thread n, where, ...
> So the information is available to the user. It doesn't have to be
> produced at the time the event is processed.
>
> I'm uncomfortable putting too much trust in waiting for the simple prompt,
> because there is too great a chance of false positives on such a small
> marker.
>
>
> On 10/17/18, 8:50 PM, Daniil Titov wrote:
> > Hi Chris, Alex and JC,
> >
> > I created a separate issue to deal with "non-atomic" jdb output at https://bugs.openjdk.java.net/browse/JDK-8212626 .
> >
> > Please review an updated fix that includes the changes Alex suggested.
> >
> > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.04
> > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> >
> > Thanks!
> > --Daniil
> >
> >
> > On 10/17/18, 5:06 PM, "Daniil Titov"<***@oracle.com> wrote:
> >
> > Hi Chris,
> >
> > The previous email was accidentally fired before I managed to type anything in. Sorry for confusion.
> >
> > Jdb constantly reads new commands from System.in despite whether the breakpoint is hit and/or the prompt is printed.
> >
> > cat -n src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
> >
> > 786 // Process interactive commands.
> > 787 MessageOutput.printPrompt();
> > 788 while (true) {
> > 789 String ln = in.readLine();
> > 790 if (ln == null) {
> > 791 /*
> > 792 * Jdb is being shutdown because debuggee exited, ignore any 'null'
> > 793 * returned by readLine() during shutdown. JDK-8154144.
> > 794 */
> > 795 if (!isShuttingDown()) {
> > 796 MessageOutput.println("Input stream closed.");
> > 797 }
> > 798 ln = "quit";
> > 799 }
> > 800
> > 801 if (ln.startsWith("!!")&& lastLine != null) {
> > 802 ln = lastLine + ln.substring(2);
> > 803 MessageOutput.printDirectln(ln);// Special case: use printDirectln()
> > 804 }
> > 805
> > 806 StringTokenizer t = new StringTokenizer(ln);
> > 807 if (t.hasMoreTokens()) {
> > 808 lastLine = ln;
> > 809 executeCommand(t);
> > 810 } else {
> > 811 MessageOutput.printPrompt();
> > 812 }
> > 813 }
> > 814 } catch (VMDisconnectedException e) {
> > 815 handler.handleDisconnectedException();
> > 816 }
> >
> > Below is a sample debug session for the following test class that sends commands "threads" and "quit"
> > 1 public class LoopTest {
> > 2 public static void main(String[] args) throws Exception {
> > 3 Thread thread = Thread.currentThread();
> > 4 while(true) {
> > 5 print(thread);
> > 6 Thread.sleep(5000);
> > 7 }
> > 8 }
> > 9
> > 10 public static void print(Object obj) {
> > 11 //System.out.println(obj);
> > 12 }
> > 13 }
> >
> > datitov-mac:work datitov$ ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest
> > Initializing jdb ...
> > > stop go at LoopTest:6
> > Deferring breakpoint LoopTest:6.
> > It will be set after the class is loaded.
> > > run
> > run LoopTest
> > Set uncaught java.lang.Throwable
> > Set deferred uncaught java.lang.Throwable
> > >
> > VM Started: Set deferred breakpoint LoopTest:6
> >
> > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > 6 Thread.sleep(5000);
> >
> > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > 6 Thread.sleep(5000);
> > 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 sleeping
> > Group InnocuousThreadGroup:
> > (jdk.internal.misc.InnocuousThread)0x197 Common-Cleaner cond. waiting
> > >
> > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > 6 Thread.sleep(5000);
> >
> > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > 6 Thread.sleep(5000);
> > quit
> > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > 6 Thread.sleep(5000);
> >
> > datitov-mac:work datitov$
> >
> > I think we could print a simple prompt in this case as Alex suggested.
> >
> > Best regards,
> > Daniil
> >
> > On 10/17/18, 3:52 PM, "Chris Plummer"<***@oracle.com> wrote:
> >
> > What is the jdb state for a breakpoint with SUSPEND_NONE? Can you
> > actually type in commands even though no threads are suspended?
> >
> > Chris
> >
> > On 10/17/18 3:31 PM, Alex Menkov wrote:
> > > Hi Daniil, Chris,
> > >
> > > As far as I understand, the fix does not completely fixes all
> > > "non-atomic" output issues (at least TTY.executeCommand still prints
> > > prompt separately), so I agree that handle it as separate issue would
> > > be better.
> > > Unfortunately I don't know Gary's ideas for the issue.
> > >
> > > About the fix for print prompt:
> > > 1) TTY.java:
> > > + // Print current location if suspend policy is SUSPEND_NONE
> > > I suppose you mean "Print breakpoint location"
> > >
> > > 2) Does it make sense to use printCurrentLocation for
> > > SUSPEND_EVENT_THREAD?
> > > Is it expected to print something different from printBreakpointLocation?
> > >
> > > 3) I don't quite understand why we don't print simple prompt for
> > > SUSPEND_NONE. IIUC jdb can accept new command in both
> > > SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb
> > > waits for next command, right?)
> > >
> > > 4) JdbStopThreadTest.java
> > > New line line in Java regexp is "\\R"
> > >
> > > --alex
> > >
> > > On 10/17/2018 10:47, Chris Plummer wrote:
> > >> Hi Alex,
> > >>
> > >> I think the tty buffering should be a separate bug fix, and I'd also
> > >> like input from Gary on it since he had tried something similar at
> > >> one point. It should probably also include a multithread test to
> > >> prove the fix is working (after first getting the test to fail
> > >> without the changes).
> > >>
> > >> thanks,
> > >>
> > >> Chris
> > >>
> > >> On 10/16/18 8:59 PM, Daniil Titov wrote:
> > >>> Hi Alex, Chris and JC,
> > >>>
> > >>> Please review an updated version of the patch that addresses these
> > >>> issues.
> > >>>
> > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
> > >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > >>>
> > >>> Thanks!
> > >>> --Daniil
> > >>>
> > >>>
> > >>> On 10/12/18, 9:52 AM, "Alex Menkov"<***@oracle.com> wrote:
> > >>>
> > >>> Hi Daniil,
> > >>> 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL
> > >>> 2) wrong indent in JdbStopThreadTest.java:
> > >>> 36 import lib.jdb.JdbCommand;
> > >>> 37 import lib.jdb.JdbTest;
> > >>> 3) I think it would be better to make waitForSimplePrompt
> > >>> property of
> > >>> JdbCommand (like JdbCommand.allowExit)
> > >>> jdb.command(JdbCommand.run().replyIsSimplePrompt());
> > >>> looks much clearer than
> > >>> jdb.command(JdbCommand.run(), true);
> > >>> 4) (TTY.java)
> > >>> MessageOutput.lnprint("Breakpoint hit:");
> > >>> + // Print current location and prompt if suspend policy is
> > >>> SUSPEND_EVENT_THREAD.
> > >>> + // In case of SUSPEND_ALL policy this is handled by
> > >>> vmInterrupted()
> > >>> method.
> > >>> + if (be.request().suspendPolicy() ==
> > >>> EventRequest.SUSPEND_EVENT_THREAD) {
> > >>> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
> > >>> + MessageOutput.printPrompt();
> > >>> + }
> > >>> We have 3 separate outputs.
> > >>> If we have several concurrent threads, we can easy get mess of
> > >>> outputs
> > >>> from different threads.
> > >>> I think it would be better to print everything in a single chunk.
> > >>> I suppose TTY has other places with similar "non-atomic"
> > >>> output, so
> > >>> maybe revising TTY output should be handled by separate issue.
> > >>> --alex
> > >>> On 10/11/2018 22:00, Chris Plummer wrote:
> > >>> > Hi Daniil,
> > >>> >
> > >>> > Can you send output from an example jdb session?
> > >>> >
> > >>> > Do you think maybe we should also call printCurrentLocation()
> > >>> when the
> > >>> > suspend policy is NONE?
> > >>> >
> > >>> > There's a typo in the following line. The space is on the
> > >>> wrong side of
> > >>> > the comma.
> > >>> >
> > >>> > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
> > >>> ,bpLine));
> > >>> >
> > >>> > thanks,
> > >>> >
> > >>> > Chris
> > >>> >
> > >>> > On 10/11/18 8:02 PM, Daniil Titov wrote:
> > >>> >>
> > >>> >> Thank you, JC!
> > >>> >>
> > >>> >> Please review an updated version of the patch that fixes
> > >>> newly added
> > >>> >> test for Windows platform (now it uses system dependent line
> > >>> >> separator string).
> > >>> >>
> > >>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
> > >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
> > >>> >>
> > >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > >>> >>
> > >>> >> Best regards,
> > >>> >>
> > >>> >> --Daniil
> > >>> >>
> > >>> >> *From: *JC Beyler<***@google.com>
> > >>> >> *Date: *Thursday, October 11, 2018 at 7:17 PM
> > >>> >> *To: *<***@oracle.com>
> > >>> >> *Cc: *<serviceability-***@openjdk.java.net>
> > >>> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when
> > >>> breakpoint
> > >>> >> is hit and suspend policy is STOP_EVENT_THREAD
> > >>> >>
> > >>> >> Hi Daniil,
> > >>> >>
> > >>> >> Looks good to me. I saw a really small nit:
> > >>> >>
> > >>> >>
> > >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
> > >>>
> > >>> >>
> > >>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
> > >>>
> > >>> >>
> > >>> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS
> > >>> ,bpLine));
> > >>> >>
> > >>> >> There is a space after the '('.
> > >>> >>
> > >>> >> No need to send a new webrev for that evidently :),
> > >>> >>
> > >>> >> Jc
> > >>> >>
> > >>> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
> > >>> >> <***@oracle.com
> > >>> <mailto:***@oracle.com>> wrote:
> > >>> >>
> > >>> >> Please review the change that fixes the issue with
> > >>> missing prompt
> > >>> >> in jdb when a breakpoint is hit and the suspend policy
> > >>> is set to
> > >>> >> stop the thread only.
> > >>> >>
> > >>> >> Webrev:
> > >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
> > >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
> > >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > >>> >>
> > >>> >> Thanks!
> > >>> >> --Daniil
> > >>> >>
> > >>> >>
> > >>> >>
> > >>> >> --
> > >>> >>
> > >>> >> Thanks,
> > >>> >>
> > >>> >> Jc
> > >>> >>
> > >>> >
> > >>>
> > >>>
> > >>
> > >>
> >
> >
> >
> >
> >
>
>
>
>
Daniil Titov
2018-10-19 16:27:01 UTC
Permalink
Hi Gary and Chris,

Below is the table that shows what jdb output is printed when a breakpoint is hit depending on what suspended policy is used:

SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED
--------------------------------------- |---------------------------|--------------------------
SUSPEND_ALL. | yes, e.g. "main[1]" | yes
--------------------------------------- |-------------------------- |--------------------------
SUSPEND_EVENT_THREAD | no | no
----------------------------------------|------------------------ --|--------------------------
SUSPEND_ALL. | no | no


The fix changes this behavior as the following:

SUSPEND POLICY | PROMPT PRINTED. | LOCATION PRINTED
--------------------------------------- |----------------------------|--------------------------
SUSPEND_ALL. | yes , e.g. "main[1]" | yes
--------------------------------------- |----------------------------|--------------------------
SUSPEND_EVENT_THREAD | yes , ">" | yes
----------------------------------------|--------------------------- |--------------------------
SUSPEND_ALL. | yes, ">". | yes

Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"?

Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here...


Thanks!

Best regards,
Daniil



On 10/19/18, 12:54 AM, "***@oracle.com" <***@oracle.com> wrote:

It's not clear to me if the omitted location information for the non
stopping
cases was intentional or not. It may be sufficient to know that the
event fired
without the extra information.

I don't think a settable prompt is required either. There are plenty of
jdb commands that
could be used with the wait for message in tests that need to
synchronize at a specific
point in the test sequence.

I don't think we see wait for simple prompt in any of the tests, because it
is not reliable enough.

On 10/18/18 11:53 AM, Daniil Titov wrote:
> Hi Gary,
>
> Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach?
>
> Thanks!
>
> Best regards,
> Daniil
>
>
>
> On 10/18/18, 4:09 AM, "Gary Adams" <***@oracle.com> wrote:
>
> I'm not certain that we should be printing locations or prompts for
> events when the vm has not been suspended. This looks OK for the
> simple test case we are working on here, but in real life there may
> be a lot more output produced.
>
> The user has to select a specific thread before additional commands
> can be performed in the correct context. e.g. threads, thread n, where, ...
> So the information is available to the user. It doesn't have to be
> produced at the time the event is processed.
>
> I'm uncomfortable putting too much trust in waiting for the simple prompt,
> because there is too great a chance of false positives on such a small
> marker.
>
>
> On 10/17/18, 8:50 PM, Daniil Titov wrote:
> > Hi Chris, Alex and JC,
> >
> > I created a separate issue to deal with "non-atomic" jdb output at https://bugs.openjdk.java.net/browse/JDK-8212626 .
> >
> > Please review an updated fix that includes the changes Alex suggested.
> >
> > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.04
> > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> >
> > Thanks!
> > --Daniil
> >
> >
> > On 10/17/18, 5:06 PM, "Daniil Titov"<***@oracle.com> wrote:
> >
> > Hi Chris,
> >
> > The previous email was accidentally fired before I managed to type anything in. Sorry for confusion.
> >
> > Jdb constantly reads new commands from System.in despite whether the breakpoint is hit and/or the prompt is printed.
> >
> > cat -n src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
> >
> > 786 // Process interactive commands.
> > 787 MessageOutput.printPrompt();
> > 788 while (true) {
> > 789 String ln = in.readLine();
> > 790 if (ln == null) {
> > 791 /*
> > 792 * Jdb is being shutdown because debuggee exited, ignore any 'null'
> > 793 * returned by readLine() during shutdown. JDK-8154144.
> > 794 */
> > 795 if (!isShuttingDown()) {
> > 796 MessageOutput.println("Input stream closed.");
> > 797 }
> > 798 ln = "quit";
> > 799 }
> > 800
> > 801 if (ln.startsWith("!!")&& lastLine != null) {
> > 802 ln = lastLine + ln.substring(2);
> > 803 MessageOutput.printDirectln(ln);// Special case: use printDirectln()
> > 804 }
> > 805
> > 806 StringTokenizer t = new StringTokenizer(ln);
> > 807 if (t.hasMoreTokens()) {
> > 808 lastLine = ln;
> > 809 executeCommand(t);
> > 810 } else {
> > 811 MessageOutput.printPrompt();
> > 812 }
> > 813 }
> > 814 } catch (VMDisconnectedException e) {
> > 815 handler.handleDisconnectedException();
> > 816 }
> >
> > Below is a sample debug session for the following test class that sends commands "threads" and "quit"
> > 1 public class LoopTest {
> > 2 public static void main(String[] args) throws Exception {
> > 3 Thread thread = Thread.currentThread();
> > 4 while(true) {
> > 5 print(thread);
> > 6 Thread.sleep(5000);
> > 7 }
> > 8 }
> > 9
> > 10 public static void print(Object obj) {
> > 11 //System.out.println(obj);
> > 12 }
> > 13 }
> >
> > datitov-mac:work datitov$ ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest
> > Initializing jdb ...
> > > stop go at LoopTest:6
> > Deferring breakpoint LoopTest:6.
> > It will be set after the class is loaded.
> > > run
> > run LoopTest
> > Set uncaught java.lang.Throwable
> > Set deferred uncaught java.lang.Throwable
> > >
> > VM Started: Set deferred breakpoint LoopTest:6
> >
> > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > 6 Thread.sleep(5000);
> >
> > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > 6 Thread.sleep(5000);
> > 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 sleeping
> > Group InnocuousThreadGroup:
> > (jdk.internal.misc.InnocuousThread)0x197 Common-Cleaner cond. waiting
> > >
> > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > 6 Thread.sleep(5000);
> >
> > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > 6 Thread.sleep(5000);
> > quit
> > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > 6 Thread.sleep(5000);
> >
> > datitov-mac:work datitov$
> >
> > I think we could print a simple prompt in this case as Alex suggested.
> >
> > Best regards,
> > Daniil
> >
> > On 10/17/18, 3:52 PM, "Chris Plummer"<***@oracle.com> wrote:
> >
> > What is the jdb state for a breakpoint with SUSPEND_NONE? Can you
> > actually type in commands even though no threads are suspended?
> >
> > Chris
> >
> > On 10/17/18 3:31 PM, Alex Menkov wrote:
> > > Hi Daniil, Chris,
> > >
> > > As far as I understand, the fix does not completely fixes all
> > > "non-atomic" output issues (at least TTY.executeCommand still prints
> > > prompt separately), so I agree that handle it as separate issue would
> > > be better.
> > > Unfortunately I don't know Gary's ideas for the issue.
> > >
> > > About the fix for print prompt:
> > > 1) TTY.java:
> > > + // Print current location if suspend policy is SUSPEND_NONE
> > > I suppose you mean "Print breakpoint location"
> > >
> > > 2) Does it make sense to use printCurrentLocation for
> > > SUSPEND_EVENT_THREAD?
> > > Is it expected to print something different from printBreakpointLocation?
> > >
> > > 3) I don't quite understand why we don't print simple prompt for
> > > SUSPEND_NONE. IIUC jdb can accept new command in both
> > > SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb
> > > waits for next command, right?)
> > >
> > > 4) JdbStopThreadTest.java
> > > New line line in Java regexp is "\\R"
> > >
> > > --alex
> > >
> > > On 10/17/2018 10:47, Chris Plummer wrote:
> > >> Hi Alex,
> > >>
> > >> I think the tty buffering should be a separate bug fix, and I'd also
> > >> like input from Gary on it since he had tried something similar at
> > >> one point. It should probably also include a multithread test to
> > >> prove the fix is working (after first getting the test to fail
> > >> without the changes).
> > >>
> > >> thanks,
> > >>
> > >> Chris
> > >>
> > >> On 10/16/18 8:59 PM, Daniil Titov wrote:
> > >>> Hi Alex, Chris and JC,
> > >>>
> > >>> Please review an updated version of the patch that addresses these
> > >>> issues.
> > >>>
> > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
> > >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > >>>
> > >>> Thanks!
> > >>> --Daniil
> > >>>
> > >>>
> > >>> On 10/12/18, 9:52 AM, "Alex Menkov"<***@oracle.com> wrote:
> > >>>
> > >>> Hi Daniil,
> > >>> 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL
> > >>> 2) wrong indent in JdbStopThreadTest.java:
> > >>> 36 import lib.jdb.JdbCommand;
> > >>> 37 import lib.jdb.JdbTest;
> > >>> 3) I think it would be better to make waitForSimplePrompt
> > >>> property of
> > >>> JdbCommand (like JdbCommand.allowExit)
> > >>> jdb.command(JdbCommand.run().replyIsSimplePrompt());
> > >>> looks much clearer than
> > >>> jdb.command(JdbCommand.run(), true);
> > >>> 4) (TTY.java)
> > >>> MessageOutput.lnprint("Breakpoint hit:");
> > >>> + // Print current location and prompt if suspend policy is
> > >>> SUSPEND_EVENT_THREAD.
> > >>> + // In case of SUSPEND_ALL policy this is handled by
> > >>> vmInterrupted()
> > >>> method.
> > >>> + if (be.request().suspendPolicy() ==
> > >>> EventRequest.SUSPEND_EVENT_THREAD) {
> > >>> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
> > >>> + MessageOutput.printPrompt();
> > >>> + }
> > >>> We have 3 separate outputs.
> > >>> If we have several concurrent threads, we can easy get mess of
> > >>> outputs
> > >>> from different threads.
> > >>> I think it would be better to print everything in a single chunk.
> > >>> I suppose TTY has other places with similar "non-atomic"
> > >>> output, so
> > >>> maybe revising TTY output should be handled by separate issue.
> > >>> --alex
> > >>> On 10/11/2018 22:00, Chris Plummer wrote:
> > >>> > Hi Daniil,
> > >>> >
> > >>> > Can you send output from an example jdb session?
> > >>> >
> > >>> > Do you think maybe we should also call printCurrentLocation()
> > >>> when the
> > >>> > suspend policy is NONE?
> > >>> >
> > >>> > There's a typo in the following line. The space is on the
> > >>> wrong side of
> > >>> > the comma.
> > >>> >
> > >>> > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
> > >>> ,bpLine));
> > >>> >
> > >>> > thanks,
> > >>> >
> > >>> > Chris
> > >>> >
> > >>> > On 10/11/18 8:02 PM, Daniil Titov wrote:
> > >>> >>
> > >>> >> Thank you, JC!
> > >>> >>
> > >>> >> Please review an updated version of the patch that fixes
> > >>> newly added
> > >>> >> test for Windows platform (now it uses system dependent line
> > >>> >> separator string).
> > >>> >>
> > >>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
> > >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
> > >>> >>
> > >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > >>> >>
> > >>> >> Best regards,
> > >>> >>
> > >>> >> --Daniil
> > >>> >>
> > >>> >> *From: *JC Beyler<***@google.com>
> > >>> >> *Date: *Thursday, October 11, 2018 at 7:17 PM
> > >>> >> *To: *<***@oracle.com>
> > >>> >> *Cc: *<serviceability-***@openjdk.java.net>
> > >>> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when
> > >>> breakpoint
> > >>> >> is hit and suspend policy is STOP_EVENT_THREAD
> > >>> >>
> > >>> >> Hi Daniil,
> > >>> >>
> > >>> >> Looks good to me. I saw a really small nit:
> > >>> >>
> > >>> >>
> > >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
> > >>>
> > >>> >>
> > >>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
> > >>>
> > >>> >>
> > >>> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS
> > >>> ,bpLine));
> > >>> >>
> > >>> >> There is a space after the '('.
> > >>> >>
> > >>> >> No need to send a new webrev for that evidently :),
> > >>> >>
> > >>> >> Jc
> > >>> >>
> > >>> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
> > >>> >> <***@oracle.com
> > >>> <mailto:***@oracle.com>> wrote:
> > >>> >>
> > >>> >> Please review the change that fixes the issue with
> > >>> missing prompt
> > >>> >> in jdb when a breakpoint is hit and the suspend policy
> > >>> is set to
> > >>> >> stop the thread only.
> > >>> >>
> > >>> >> Webrev:
> > >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
> > >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
> > >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > >>> >>
> > >>> >> Thanks!
> > >>> >> --Daniil
> > >>> >>
> > >>> >>
> > >>> >>
> > >>> >> --
> > >>> >>
> > >>> >> Thanks,
> > >>> >>
> > >>> >> Jc
> > >>> >>
> > >>> >
> > >>>
> > >>>
> > >>
> > >>
> >
> >
> >
> >
> >
>
>
>
>
Daniil Titov
2018-10-19 16:47:23 UTC
Permalink
Hi Gary and Chris,

I am resending the previous email since the table in that email got corrupted.

Below is what output jdb prints when a breakpoint is hit depending on what suspended policy is used:

The current behavior.
SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed
SUSPEND_EVENT_THREAD: Prompt is not printed, location is not printed
SUSPEND_NONE: Prompt is not printed, location is not printed

The fix changes this behavior as the following:

SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed
SUSPEND_EVENT_THREAD: Prompt is printed ( "> "), location is printed
SUSPEND_NONE: Prompt is printed ( "> "), location is printed

Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"?

Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here...


Thanks!
--Daniil

On 10/19/18, 9:27 AM, "Daniil Titov" <***@oracle.com> wrote:

Hi Gary and Chris,

Below is the table that shows what jdb output is printed when a breakpoint is hit depending on what suspended policy is used:

SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED
--------------------------------------- |---------------------------|--------------------------
SUSPEND_ALL. | yes, e.g. "main[1]" | yes
--------------------------------------- |-------------------------- |--------------------------
SUSPEND_EVENT_THREAD | no | no
----------------------------------------|------------------------ --|--------------------------
SUSPEND_ALL. | no | no


The fix changes this behavior as the following:

SUSPEND POLICY | PROMPT PRINTED. | LOCATION PRINTED
--------------------------------------- |----------------------------|--------------------------
SUSPEND_ALL. | yes , e.g. "main[1]" | yes
--------------------------------------- |----------------------------|--------------------------
SUSPEND_EVENT_THREAD | yes , ">" | yes
----------------------------------------|--------------------------- |--------------------------
SUSPEND_ALL. | yes, ">". | yes

Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"?

Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here...


Thanks!

Best regards,
Daniil



On 10/19/18, 12:54 AM, "***@oracle.com" <***@oracle.com> wrote:

It's not clear to me if the omitted location information for the non
stopping
cases was intentional or not. It may be sufficient to know that the
event fired
without the extra information.

I don't think a settable prompt is required either. There are plenty of
jdb commands that
could be used with the wait for message in tests that need to
synchronize at a specific
point in the test sequence.

I don't think we see wait for simple prompt in any of the tests, because it
is not reliable enough.

On 10/18/18 11:53 AM, Daniil Titov wrote:
> Hi Gary,
>
> Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach?
>
> Thanks!
>
> Best regards,
> Daniil
>
>
>
> On 10/18/18, 4:09 AM, "Gary Adams" <***@oracle.com> wrote:
>
> I'm not certain that we should be printing locations or prompts for
> events when the vm has not been suspended. This looks OK for the
> simple test case we are working on here, but in real life there may
> be a lot more output produced.
>
> The user has to select a specific thread before additional commands
> can be performed in the correct context. e.g. threads, thread n, where, ...
> So the information is available to the user. It doesn't have to be
> produced at the time the event is processed.
>
> I'm uncomfortable putting too much trust in waiting for the simple prompt,
> because there is too great a chance of false positives on such a small
> marker.
>
>
> On 10/17/18, 8:50 PM, Daniil Titov wrote:
> > Hi Chris, Alex and JC,
> >
> > I created a separate issue to deal with "non-atomic" jdb output at https://bugs.openjdk.java.net/browse/JDK-8212626 .
> >
> > Please review an updated fix that includes the changes Alex suggested.
> >
> > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.04
> > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> >
> > Thanks!
> > --Daniil
> >
> >
> > On 10/17/18, 5:06 PM, "Daniil Titov"<***@oracle.com> wrote:
> >
> > Hi Chris,
> >
> > The previous email was accidentally fired before I managed to type anything in. Sorry for confusion.
> >
> > Jdb constantly reads new commands from System.in despite whether the breakpoint is hit and/or the prompt is printed.
> >
> > cat -n src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
> >
> > 786 // Process interactive commands.
> > 787 MessageOutput.printPrompt();
> > 788 while (true) {
> > 789 String ln = in.readLine();
> > 790 if (ln == null) {
> > 791 /*
> > 792 * Jdb is being shutdown because debuggee exited, ignore any 'null'
> > 793 * returned by readLine() during shutdown. JDK-8154144.
> > 794 */
> > 795 if (!isShuttingDown()) {
> > 796 MessageOutput.println("Input stream closed.");
> > 797 }
> > 798 ln = "quit";
> > 799 }
> > 800
> > 801 if (ln.startsWith("!!")&& lastLine != null) {
> > 802 ln = lastLine + ln.substring(2);
> > 803 MessageOutput.printDirectln(ln);// Special case: use printDirectln()
> > 804 }
> > 805
> > 806 StringTokenizer t = new StringTokenizer(ln);
> > 807 if (t.hasMoreTokens()) {
> > 808 lastLine = ln;
> > 809 executeCommand(t);
> > 810 } else {
> > 811 MessageOutput.printPrompt();
> > 812 }
> > 813 }
> > 814 } catch (VMDisconnectedException e) {
> > 815 handler.handleDisconnectedException();
> > 816 }
> >
> > Below is a sample debug session for the following test class that sends commands "threads" and "quit"
> > 1 public class LoopTest {
> > 2 public static void main(String[] args) throws Exception {
> > 3 Thread thread = Thread.currentThread();
> > 4 while(true) {
> > 5 print(thread);
> > 6 Thread.sleep(5000);
> > 7 }
> > 8 }
> > 9
> > 10 public static void print(Object obj) {
> > 11 //System.out.println(obj);
> > 12 }
> > 13 }
> >
> > datitov-mac:work datitov$ ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest
> > Initializing jdb ...
> > > stop go at LoopTest:6
> > Deferring breakpoint LoopTest:6.
> > It will be set after the class is loaded.
> > > run
> > run LoopTest
> > Set uncaught java.lang.Throwable
> > Set deferred uncaught java.lang.Throwable
> > >
> > VM Started: Set deferred breakpoint LoopTest:6
> >
> > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > 6 Thread.sleep(5000);
> >
> > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > 6 Thread.sleep(5000);
> > 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 sleeping
> > Group InnocuousThreadGroup:
> > (jdk.internal.misc.InnocuousThread)0x197 Common-Cleaner cond. waiting
> > >
> > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > 6 Thread.sleep(5000);
> >
> > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > 6 Thread.sleep(5000);
> > quit
> > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > 6 Thread.sleep(5000);
> >
> > datitov-mac:work datitov$
> >
> > I think we could print a simple prompt in this case as Alex suggested.
> >
> > Best regards,
> > Daniil
> >
> > On 10/17/18, 3:52 PM, "Chris Plummer"<***@oracle.com> wrote:
> >
> > What is the jdb state for a breakpoint with SUSPEND_NONE? Can you
> > actually type in commands even though no threads are suspended?
> >
> > Chris
> >
> > On 10/17/18 3:31 PM, Alex Menkov wrote:
> > > Hi Daniil, Chris,
> > >
> > > As far as I understand, the fix does not completely fixes all
> > > "non-atomic" output issues (at least TTY.executeCommand still prints
> > > prompt separately), so I agree that handle it as separate issue would
> > > be better.
> > > Unfortunately I don't know Gary's ideas for the issue.
> > >
> > > About the fix for print prompt:
> > > 1) TTY.java:
> > > + // Print current location if suspend policy is SUSPEND_NONE
> > > I suppose you mean "Print breakpoint location"
> > >
> > > 2) Does it make sense to use printCurrentLocation for
> > > SUSPEND_EVENT_THREAD?
> > > Is it expected to print something different from printBreakpointLocation?
> > >
> > > 3) I don't quite understand why we don't print simple prompt for
> > > SUSPEND_NONE. IIUC jdb can accept new command in both
> > > SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb
> > > waits for next command, right?)
> > >
> > > 4) JdbStopThreadTest.java
> > > New line line in Java regexp is "\\R"
> > >
> > > --alex
> > >
> > > On 10/17/2018 10:47, Chris Plummer wrote:
> > >> Hi Alex,
> > >>
> > >> I think the tty buffering should be a separate bug fix, and I'd also
> > >> like input from Gary on it since he had tried something similar at
> > >> one point. It should probably also include a multithread test to
> > >> prove the fix is working (after first getting the test to fail
> > >> without the changes).
> > >>
> > >> thanks,
> > >>
> > >> Chris
> > >>
> > >> On 10/16/18 8:59 PM, Daniil Titov wrote:
> > >>> Hi Alex, Chris and JC,
> > >>>
> > >>> Please review an updated version of the patch that addresses these
> > >>> issues.
> > >>>
> > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
> > >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > >>>
> > >>> Thanks!
> > >>> --Daniil
> > >>>
> > >>>
> > >>> On 10/12/18, 9:52 AM, "Alex Menkov"<***@oracle.com> wrote:
> > >>>
> > >>> Hi Daniil,
> > >>> 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL
> > >>> 2) wrong indent in JdbStopThreadTest.java:
> > >>> 36 import lib.jdb.JdbCommand;
> > >>> 37 import lib.jdb.JdbTest;
> > >>> 3) I think it would be better to make waitForSimplePrompt
> > >>> property of
> > >>> JdbCommand (like JdbCommand.allowExit)
> > >>> jdb.command(JdbCommand.run().replyIsSimplePrompt());
> > >>> looks much clearer than
> > >>> jdb.command(JdbCommand.run(), true);
> > >>> 4) (TTY.java)
> > >>> MessageOutput.lnprint("Breakpoint hit:");
> > >>> + // Print current location and prompt if suspend policy is
> > >>> SUSPEND_EVENT_THREAD.
> > >>> + // In case of SUSPEND_ALL policy this is handled by
> > >>> vmInterrupted()
> > >>> method.
> > >>> + if (be.request().suspendPolicy() ==
> > >>> EventRequest.SUSPEND_EVENT_THREAD) {
> > >>> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
> > >>> + MessageOutput.printPrompt();
> > >>> + }
> > >>> We have 3 separate outputs.
> > >>> If we have several concurrent threads, we can easy get mess of
> > >>> outputs
> > >>> from different threads.
> > >>> I think it would be better to print everything in a single chunk.
> > >>> I suppose TTY has other places with similar "non-atomic"
> > >>> output, so
> > >>> maybe revising TTY output should be handled by separate issue.
> > >>> --alex
> > >>> On 10/11/2018 22:00, Chris Plummer wrote:
> > >>> > Hi Daniil,
> > >>> >
> > >>> > Can you send output from an example jdb session?
> > >>> >
> > >>> > Do you think maybe we should also call printCurrentLocation()
> > >>> when the
> > >>> > suspend policy is NONE?
> > >>> >
> > >>> > There's a typo in the following line. The space is on the
> > >>> wrong side of
> > >>> > the comma.
> > >>> >
> > >>> > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
> > >>> ,bpLine));
> > >>> >
> > >>> > thanks,
> > >>> >
> > >>> > Chris
> > >>> >
> > >>> > On 10/11/18 8:02 PM, Daniil Titov wrote:
> > >>> >>
> > >>> >> Thank you, JC!
> > >>> >>
> > >>> >> Please review an updated version of the patch that fixes
> > >>> newly added
> > >>> >> test for Windows platform (now it uses system dependent line
> > >>> >> separator string).
> > >>> >>
> > >>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
> > >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
> > >>> >>
> > >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > >>> >>
> > >>> >> Best regards,
> > >>> >>
> > >>> >> --Daniil
> > >>> >>
> > >>> >> *From: *JC Beyler<***@google.com>
> > >>> >> *Date: *Thursday, October 11, 2018 at 7:17 PM
> > >>> >> *To: *<***@oracle.com>
> > >>> >> *Cc: *<serviceability-***@openjdk.java.net>
> > >>> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when
> > >>> breakpoint
> > >>> >> is hit and suspend policy is STOP_EVENT_THREAD
> > >>> >>
> > >>> >> Hi Daniil,
> > >>> >>
> > >>> >> Looks good to me. I saw a really small nit:
> > >>> >>
> > >>> >>
> > >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
> > >>>
> > >>> >>
> > >>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
> > >>>
> > >>> >>
> > >>> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS
> > >>> ,bpLine));
> > >>> >>
> > >>> >> There is a space after the '('.
> > >>> >>
> > >>> >> No need to send a new webrev for that evidently :),
> > >>> >>
> > >>> >> Jc
> > >>> >>
> > >>> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
> > >>> >> <***@oracle.com
> > >>> <mailto:***@oracle.com>> wrote:
> > >>> >>
> > >>> >> Please review the change that fixes the issue with
> > >>> missing prompt
> > >>> >> in jdb when a breakpoint is hit and the suspend policy
> > >>> is set to
> > >>> >> stop the thread only.
> > >>> >>
> > >>> >> Webrev:
> > >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
> > >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
> > >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > >>> >>
> > >>> >> Thanks!
> > >>> >> --Daniil
> > >>> >>
> > >>> >>
> > >>> >>
> > >>> >> --
> > >>> >>
> > >>> >> Thanks,
> > >>> >>
> > >>> >> Jc
> > >>> >>
> > >>> >
> > >>>
> > >>>
> > >>
> > >>
> >
> >
> >
> >
> >
>
>
>
>
Chris Plummer
2018-10-19 19:55:42 UTC
Permalink
On 10/19/18 9:47 AM, Daniil Titov wrote:
> Hi Gary and Chris,
>
> I am resending the previous email since the table in that email got corrupted.
>
> Below is what output jdb prints when a breakpoint is hit depending on what suspended policy is used:
>
> The current behavior.
> SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed
> SUSPEND_EVENT_THREAD: Prompt is not printed, location is not printed
> SUSPEND_NONE: Prompt is not printed, location is not printed
>
> The fix changes this behavior as the following:
>
> SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed
> SUSPEND_EVENT_THREAD: Prompt is printed ( "> "), location is printed
> SUSPEND_NONE: Prompt is printed ( "> "), location is printed
I'm still in favor of this fix.
>
>
> Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"?
>
> Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here...
Maybe we need a version of command() that takes a pattern to look for
other than the prompt.

Chris
>
>
> Thanks!
> --Daniil
>
> On 10/19/18, 9:27 AM, "Daniil Titov" <***@oracle.com> wrote:
>
> Hi Gary and Chris,
>
> Below is the table that shows what jdb output is printed when a breakpoint is hit depending on what suspended policy is used:
>
> SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED
> --------------------------------------- |---------------------------|--------------------------
> SUSPEND_ALL. | yes, e.g. "main[1]" | yes
> --------------------------------------- |-------------------------- |--------------------------
> SUSPEND_EVENT_THREAD | no | no
> ----------------------------------------|------------------------ --|--------------------------
> SUSPEND_ALL. | no | no
>
>
> The fix changes this behavior as the following:
>
> SUSPEND POLICY | PROMPT PRINTED. | LOCATION PRINTED
> --------------------------------------- |----------------------------|--------------------------
> SUSPEND_ALL. | yes , e.g. "main[1]" | yes
> --------------------------------------- |----------------------------|--------------------------
> SUSPEND_EVENT_THREAD | yes , ">" | yes
> ----------------------------------------|--------------------------- |--------------------------
> SUSPEND_ALL. | yes, ">". | yes
>
> Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"?
>
> Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here...
>
>
> Thanks!
>
> Best regards,
> Daniil
>
>
>
> On 10/19/18, 12:54 AM, "***@oracle.com" <***@oracle.com> wrote:
>
> It's not clear to me if the omitted location information for the non
> stopping
> cases was intentional or not. It may be sufficient to know that the
> event fired
> without the extra information.
>
> I don't think a settable prompt is required either. There are plenty of
> jdb commands that
> could be used with the wait for message in tests that need to
> synchronize at a specific
> point in the test sequence.
>
> I don't think we see wait for simple prompt in any of the tests, because it
> is not reliable enough.
>
> On 10/18/18 11:53 AM, Daniil Titov wrote:
> > Hi Gary,
> >
> > Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach?
> >
> > Thanks!
> >
> > Best regards,
> > Daniil
> >
> >
> >
> > On 10/18/18, 4:09 AM, "Gary Adams" <***@oracle.com> wrote:
> >
> > I'm not certain that we should be printing locations or prompts for
> > events when the vm has not been suspended. This looks OK for the
> > simple test case we are working on here, but in real life there may
> > be a lot more output produced.
> >
> > The user has to select a specific thread before additional commands
> > can be performed in the correct context. e.g. threads, thread n, where, ...
> > So the information is available to the user. It doesn't have to be
> > produced at the time the event is processed.
> >
> > I'm uncomfortable putting too much trust in waiting for the simple prompt,
> > because there is too great a chance of false positives on such a small
> > marker.
> >
> >
> > On 10/17/18, 8:50 PM, Daniil Titov wrote:
> > > Hi Chris, Alex and JC,
> > >
> > > I created a separate issue to deal with "non-atomic" jdb output at https://bugs.openjdk.java.net/browse/JDK-8212626 .
> > >
> > > Please review an updated fix that includes the changes Alex suggested.
> > >
> > > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.04
> > > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > >
> > > Thanks!
> > > --Daniil
> > >
> > >
> > > On 10/17/18, 5:06 PM, "Daniil Titov"<***@oracle.com> wrote:
> > >
> > > Hi Chris,
> > >
> > > The previous email was accidentally fired before I managed to type anything in. Sorry for confusion.
> > >
> > > Jdb constantly reads new commands from System.in despite whether the breakpoint is hit and/or the prompt is printed.
> > >
> > > cat -n src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
> > >
> > > 786 // Process interactive commands.
> > > 787 MessageOutput.printPrompt();
> > > 788 while (true) {
> > > 789 String ln = in.readLine();
> > > 790 if (ln == null) {
> > > 791 /*
> > > 792 * Jdb is being shutdown because debuggee exited, ignore any 'null'
> > > 793 * returned by readLine() during shutdown. JDK-8154144.
> > > 794 */
> > > 795 if (!isShuttingDown()) {
> > > 796 MessageOutput.println("Input stream closed.");
> > > 797 }
> > > 798 ln = "quit";
> > > 799 }
> > > 800
> > > 801 if (ln.startsWith("!!")&& lastLine != null) {
> > > 802 ln = lastLine + ln.substring(2);
> > > 803 MessageOutput.printDirectln(ln);// Special case: use printDirectln()
> > > 804 }
> > > 805
> > > 806 StringTokenizer t = new StringTokenizer(ln);
> > > 807 if (t.hasMoreTokens()) {
> > > 808 lastLine = ln;
> > > 809 executeCommand(t);
> > > 810 } else {
> > > 811 MessageOutput.printPrompt();
> > > 812 }
> > > 813 }
> > > 814 } catch (VMDisconnectedException e) {
> > > 815 handler.handleDisconnectedException();
> > > 816 }
> > >
> > > Below is a sample debug session for the following test class that sends commands "threads" and "quit"
> > > 1 public class LoopTest {
> > > 2 public static void main(String[] args) throws Exception {
> > > 3 Thread thread = Thread.currentThread();
> > > 4 while(true) {
> > > 5 print(thread);
> > > 6 Thread.sleep(5000);
> > > 7 }
> > > 8 }
> > > 9
> > > 10 public static void print(Object obj) {
> > > 11 //System.out.println(obj);
> > > 12 }
> > > 13 }
> > >
> > > datitov-mac:work datitov$ ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest
> > > Initializing jdb ...
> > > > stop go at LoopTest:6
> > > Deferring breakpoint LoopTest:6.
> > > It will be set after the class is loaded.
> > > > run
> > > run LoopTest
> > > Set uncaught java.lang.Throwable
> > > Set deferred uncaught java.lang.Throwable
> > > >
> > > VM Started: Set deferred breakpoint LoopTest:6
> > >
> > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > 6 Thread.sleep(5000);
> > >
> > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > 6 Thread.sleep(5000);
> > > 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 sleeping
> > > Group InnocuousThreadGroup:
> > > (jdk.internal.misc.InnocuousThread)0x197 Common-Cleaner cond. waiting
> > > >
> > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > 6 Thread.sleep(5000);
> > >
> > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > 6 Thread.sleep(5000);
> > > quit
> > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > 6 Thread.sleep(5000);
> > >
> > > datitov-mac:work datitov$
> > >
> > > I think we could print a simple prompt in this case as Alex suggested.
> > >
> > > Best regards,
> > > Daniil
> > >
> > > On 10/17/18, 3:52 PM, "Chris Plummer"<***@oracle.com> wrote:
> > >
> > > What is the jdb state for a breakpoint with SUSPEND_NONE? Can you
> > > actually type in commands even though no threads are suspended?
> > >
> > > Chris
> > >
> > > On 10/17/18 3:31 PM, Alex Menkov wrote:
> > > > Hi Daniil, Chris,
> > > >
> > > > As far as I understand, the fix does not completely fixes all
> > > > "non-atomic" output issues (at least TTY.executeCommand still prints
> > > > prompt separately), so I agree that handle it as separate issue would
> > > > be better.
> > > > Unfortunately I don't know Gary's ideas for the issue.
> > > >
> > > > About the fix for print prompt:
> > > > 1) TTY.java:
> > > > + // Print current location if suspend policy is SUSPEND_NONE
> > > > I suppose you mean "Print breakpoint location"
> > > >
> > > > 2) Does it make sense to use printCurrentLocation for
> > > > SUSPEND_EVENT_THREAD?
> > > > Is it expected to print something different from printBreakpointLocation?
> > > >
> > > > 3) I don't quite understand why we don't print simple prompt for
> > > > SUSPEND_NONE. IIUC jdb can accept new command in both
> > > > SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb
> > > > waits for next command, right?)
> > > >
> > > > 4) JdbStopThreadTest.java
> > > > New line line in Java regexp is "\\R"
> > > >
> > > > --alex
> > > >
> > > > On 10/17/2018 10:47, Chris Plummer wrote:
> > > >> Hi Alex,
> > > >>
> > > >> I think the tty buffering should be a separate bug fix, and I'd also
> > > >> like input from Gary on it since he had tried something similar at
> > > >> one point. It should probably also include a multithread test to
> > > >> prove the fix is working (after first getting the test to fail
> > > >> without the changes).
> > > >>
> > > >> thanks,
> > > >>
> > > >> Chris
> > > >>
> > > >> On 10/16/18 8:59 PM, Daniil Titov wrote:
> > > >>> Hi Alex, Chris and JC,
> > > >>>
> > > >>> Please review an updated version of the patch that addresses these
> > > >>> issues.
> > > >>>
> > > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
> > > >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > >>>
> > > >>> Thanks!
> > > >>> --Daniil
> > > >>>
> > > >>>
> > > >>> On 10/12/18, 9:52 AM, "Alex Menkov"<***@oracle.com> wrote:
> > > >>>
> > > >>> Hi Daniil,
> > > >>> 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL
> > > >>> 2) wrong indent in JdbStopThreadTest.java:
> > > >>> 36 import lib.jdb.JdbCommand;
> > > >>> 37 import lib.jdb.JdbTest;
> > > >>> 3) I think it would be better to make waitForSimplePrompt
> > > >>> property of
> > > >>> JdbCommand (like JdbCommand.allowExit)
> > > >>> jdb.command(JdbCommand.run().replyIsSimplePrompt());
> > > >>> looks much clearer than
> > > >>> jdb.command(JdbCommand.run(), true);
> > > >>> 4) (TTY.java)
> > > >>> MessageOutput.lnprint("Breakpoint hit:");
> > > >>> + // Print current location and prompt if suspend policy is
> > > >>> SUSPEND_EVENT_THREAD.
> > > >>> + // In case of SUSPEND_ALL policy this is handled by
> > > >>> vmInterrupted()
> > > >>> method.
> > > >>> + if (be.request().suspendPolicy() ==
> > > >>> EventRequest.SUSPEND_EVENT_THREAD) {
> > > >>> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
> > > >>> + MessageOutput.printPrompt();
> > > >>> + }
> > > >>> We have 3 separate outputs.
> > > >>> If we have several concurrent threads, we can easy get mess of
> > > >>> outputs
> > > >>> from different threads.
> > > >>> I think it would be better to print everything in a single chunk.
> > > >>> I suppose TTY has other places with similar "non-atomic"
> > > >>> output, so
> > > >>> maybe revising TTY output should be handled by separate issue.
> > > >>> --alex
> > > >>> On 10/11/2018 22:00, Chris Plummer wrote:
> > > >>> > Hi Daniil,
> > > >>> >
> > > >>> > Can you send output from an example jdb session?
> > > >>> >
> > > >>> > Do you think maybe we should also call printCurrentLocation()
> > > >>> when the
> > > >>> > suspend policy is NONE?
> > > >>> >
> > > >>> > There's a typo in the following line. The space is on the
> > > >>> wrong side of
> > > >>> > the comma.
> > > >>> >
> > > >>> > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
> > > >>> ,bpLine));
> > > >>> >
> > > >>> > thanks,
> > > >>> >
> > > >>> > Chris
> > > >>> >
> > > >>> > On 10/11/18 8:02 PM, Daniil Titov wrote:
> > > >>> >>
> > > >>> >> Thank you, JC!
> > > >>> >>
> > > >>> >> Please review an updated version of the patch that fixes
> > > >>> newly added
> > > >>> >> test for Windows platform (now it uses system dependent line
> > > >>> >> separator string).
> > > >>> >>
> > > >>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
> > > >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
> > > >>> >>
> > > >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > >>> >>
> > > >>> >> Best regards,
> > > >>> >>
> > > >>> >> --Daniil
> > > >>> >>
> > > >>> >> *From: *JC Beyler<***@google.com>
> > > >>> >> *Date: *Thursday, October 11, 2018 at 7:17 PM
> > > >>> >> *To: *<***@oracle.com>
> > > >>> >> *Cc: *<serviceability-***@openjdk.java.net>
> > > >>> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when
> > > >>> breakpoint
> > > >>> >> is hit and suspend policy is STOP_EVENT_THREAD
> > > >>> >>
> > > >>> >> Hi Daniil,
> > > >>> >>
> > > >>> >> Looks good to me. I saw a really small nit:
> > > >>> >>
> > > >>> >>
> > > >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
> > > >>>
> > > >>> >>
> > > >>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
> > > >>>
> > > >>> >>
> > > >>> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS
> > > >>> ,bpLine));
> > > >>> >>
> > > >>> >> There is a space after the '('.
> > > >>> >>
> > > >>> >> No need to send a new webrev for that evidently :),
> > > >>> >>
> > > >>> >> Jc
> > > >>> >>
> > > >>> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
> > > >>> >> <***@oracle.com
> > > >>> <mailto:***@oracle.com>> wrote:
> > > >>> >>
> > > >>> >> Please review the change that fixes the issue with
> > > >>> missing prompt
> > > >>> >> in jdb when a breakpoint is hit and the suspend policy
> > > >>> is set to
> > > >>> >> stop the thread only.
> > > >>> >>
> > > >>> >> Webrev:
> > > >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
> > > >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
> > > >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > >>> >>
> > > >>> >> Thanks!
> > > >>> >> --Daniil
> > > >>> >>
> > > >>> >>
> > > >>> >>
> > > >>> >> --
> > > >>> >>
> > > >>> >> Thanks,
> > > >>> >>
> > > >>> >> Jc
> > > >>> >>
> > > >>> >
> > > >>>
> > > >>>
> > > >>
> > > >>
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
>
Daniil Titov
2018-10-19 23:01:20 UTC
Permalink
Hi Chris,

Please review an updated version of the fix that makes the tests to use a custom pattern while waiting for the command to complete.

Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/
Issue: https://bugs.openjdk.java.net/browse/JDK-8211736

Thanks!
--Daniil


On 10/19/18, 12:55 PM, "Chris Plummer" <***@oracle.com> wrote:

On 10/19/18 9:47 AM, Daniil Titov wrote:
> Hi Gary and Chris,
>
> I am resending the previous email since the table in that email got corrupted.
>
> Below is what output jdb prints when a breakpoint is hit depending on what suspended policy is used:
>
> The current behavior.
> SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed
> SUSPEND_EVENT_THREAD: Prompt is not printed, location is not printed
> SUSPEND_NONE: Prompt is not printed, location is not printed
>
> The fix changes this behavior as the following:
>
> SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed
> SUSPEND_EVENT_THREAD: Prompt is printed ( "> "), location is printed
> SUSPEND_NONE: Prompt is printed ( "> "), location is printed
I'm still in favor of this fix.
>
>
> Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"?
>
> Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here...
Maybe we need a version of command() that takes a pattern to look for
other than the prompt.

Chris
>
>
> Thanks!
> --Daniil
>
> On 10/19/18, 9:27 AM, "Daniil Titov" <***@oracle.com> wrote:
>
> Hi Gary and Chris,
>
> Below is the table that shows what jdb output is printed when a breakpoint is hit depending on what suspended policy is used:
>
> SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED
> --------------------------------------- |---------------------------|--------------------------
> SUSPEND_ALL. | yes, e.g. "main[1]" | yes
> --------------------------------------- |-------------------------- |--------------------------
> SUSPEND_EVENT_THREAD | no | no
> ----------------------------------------|------------------------ --|--------------------------
> SUSPEND_ALL. | no | no
>
>
> The fix changes this behavior as the following:
>
> SUSPEND POLICY | PROMPT PRINTED. | LOCATION PRINTED
> --------------------------------------- |----------------------------|--------------------------
> SUSPEND_ALL. | yes , e.g. "main[1]" | yes
> --------------------------------------- |----------------------------|--------------------------
> SUSPEND_EVENT_THREAD | yes , ">" | yes
> ----------------------------------------|--------------------------- |--------------------------
> SUSPEND_ALL. | yes, ">". | yes
>
> Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"?
>
> Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here...
>
>
> Thanks!
>
> Best regards,
> Daniil
>
>
>
> On 10/19/18, 12:54 AM, "***@oracle.com" <***@oracle.com> wrote:
>
> It's not clear to me if the omitted location information for the non
> stopping
> cases was intentional or not. It may be sufficient to know that the
> event fired
> without the extra information.
>
> I don't think a settable prompt is required either. There are plenty of
> jdb commands that
> could be used with the wait for message in tests that need to
> synchronize at a specific
> point in the test sequence.
>
> I don't think we see wait for simple prompt in any of the tests, because it
> is not reliable enough.
>
> On 10/18/18 11:53 AM, Daniil Titov wrote:
> > Hi Gary,
> >
> > Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach?
> >
> > Thanks!
> >
> > Best regards,
> > Daniil
> >
> >
> >
> > On 10/18/18, 4:09 AM, "Gary Adams" <***@oracle.com> wrote:
> >
> > I'm not certain that we should be printing locations or prompts for
> > events when the vm has not been suspended. This looks OK for the
> > simple test case we are working on here, but in real life there may
> > be a lot more output produced.
> >
> > The user has to select a specific thread before additional commands
> > can be performed in the correct context. e.g. threads, thread n, where, ...
> > So the information is available to the user. It doesn't have to be
> > produced at the time the event is processed.
> >
> > I'm uncomfortable putting too much trust in waiting for the simple prompt,
> > because there is too great a chance of false positives on such a small
> > marker.
> >
> >
> > On 10/17/18, 8:50 PM, Daniil Titov wrote:
> > > Hi Chris, Alex and JC,
> > >
> > > I created a separate issue to deal with "non-atomic" jdb output at https://bugs.openjdk.java.net/browse/JDK-8212626 .
> > >
> > > Please review an updated fix that includes the changes Alex suggested.
> > >
> > > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.04
> > > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > >
> > > Thanks!
> > > --Daniil
> > >
> > >
> > > On 10/17/18, 5:06 PM, "Daniil Titov"<***@oracle.com> wrote:
> > >
> > > Hi Chris,
> > >
> > > The previous email was accidentally fired before I managed to type anything in. Sorry for confusion.
> > >
> > > Jdb constantly reads new commands from System.in despite whether the breakpoint is hit and/or the prompt is printed.
> > >
> > > cat -n src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
> > >
> > > 786 // Process interactive commands.
> > > 787 MessageOutput.printPrompt();
> > > 788 while (true) {
> > > 789 String ln = in.readLine();
> > > 790 if (ln == null) {
> > > 791 /*
> > > 792 * Jdb is being shutdown because debuggee exited, ignore any 'null'
> > > 793 * returned by readLine() during shutdown. JDK-8154144.
> > > 794 */
> > > 795 if (!isShuttingDown()) {
> > > 796 MessageOutput.println("Input stream closed.");
> > > 797 }
> > > 798 ln = "quit";
> > > 799 }
> > > 800
> > > 801 if (ln.startsWith("!!")&& lastLine != null) {
> > > 802 ln = lastLine + ln.substring(2);
> > > 803 MessageOutput.printDirectln(ln);// Special case: use printDirectln()
> > > 804 }
> > > 805
> > > 806 StringTokenizer t = new StringTokenizer(ln);
> > > 807 if (t.hasMoreTokens()) {
> > > 808 lastLine = ln;
> > > 809 executeCommand(t);
> > > 810 } else {
> > > 811 MessageOutput.printPrompt();
> > > 812 }
> > > 813 }
> > > 814 } catch (VMDisconnectedException e) {
> > > 815 handler.handleDisconnectedException();
> > > 816 }
> > >
> > > Below is a sample debug session for the following test class that sends commands "threads" and "quit"
> > > 1 public class LoopTest {
> > > 2 public static void main(String[] args) throws Exception {
> > > 3 Thread thread = Thread.currentThread();
> > > 4 while(true) {
> > > 5 print(thread);
> > > 6 Thread.sleep(5000);
> > > 7 }
> > > 8 }
> > > 9
> > > 10 public static void print(Object obj) {
> > > 11 //System.out.println(obj);
> > > 12 }
> > > 13 }
> > >
> > > datitov-mac:work datitov$ ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest
> > > Initializing jdb ...
> > > > stop go at LoopTest:6
> > > Deferring breakpoint LoopTest:6.
> > > It will be set after the class is loaded.
> > > > run
> > > run LoopTest
> > > Set uncaught java.lang.Throwable
> > > Set deferred uncaught java.lang.Throwable
> > > >
> > > VM Started: Set deferred breakpoint LoopTest:6
> > >
> > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > 6 Thread.sleep(5000);
> > >
> > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > 6 Thread.sleep(5000);
> > > 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 sleeping
> > > Group InnocuousThreadGroup:
> > > (jdk.internal.misc.InnocuousThread)0x197 Common-Cleaner cond. waiting
> > > >
> > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > 6 Thread.sleep(5000);
> > >
> > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > 6 Thread.sleep(5000);
> > > quit
> > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > 6 Thread.sleep(5000);
> > >
> > > datitov-mac:work datitov$
> > >
> > > I think we could print a simple prompt in this case as Alex suggested.
> > >
> > > Best regards,
> > > Daniil
> > >
> > > On 10/17/18, 3:52 PM, "Chris Plummer"<***@oracle.com> wrote:
> > >
> > > What is the jdb state for a breakpoint with SUSPEND_NONE? Can you
> > > actually type in commands even though no threads are suspended?
> > >
> > > Chris
> > >
> > > On 10/17/18 3:31 PM, Alex Menkov wrote:
> > > > Hi Daniil, Chris,
> > > >
> > > > As far as I understand, the fix does not completely fixes all
> > > > "non-atomic" output issues (at least TTY.executeCommand still prints
> > > > prompt separately), so I agree that handle it as separate issue would
> > > > be better.
> > > > Unfortunately I don't know Gary's ideas for the issue.
> > > >
> > > > About the fix for print prompt:
> > > > 1) TTY.java:
> > > > + // Print current location if suspend policy is SUSPEND_NONE
> > > > I suppose you mean "Print breakpoint location"
> > > >
> > > > 2) Does it make sense to use printCurrentLocation for
> > > > SUSPEND_EVENT_THREAD?
> > > > Is it expected to print something different from printBreakpointLocation?
> > > >
> > > > 3) I don't quite understand why we don't print simple prompt for
> > > > SUSPEND_NONE. IIUC jdb can accept new command in both
> > > > SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb
> > > > waits for next command, right?)
> > > >
> > > > 4) JdbStopThreadTest.java
> > > > New line line in Java regexp is "\\R"
> > > >
> > > > --alex
> > > >
> > > > On 10/17/2018 10:47, Chris Plummer wrote:
> > > >> Hi Alex,
> > > >>
> > > >> I think the tty buffering should be a separate bug fix, and I'd also
> > > >> like input from Gary on it since he had tried something similar at
> > > >> one point. It should probably also include a multithread test to
> > > >> prove the fix is working (after first getting the test to fail
> > > >> without the changes).
> > > >>
> > > >> thanks,
> > > >>
> > > >> Chris
> > > >>
> > > >> On 10/16/18 8:59 PM, Daniil Titov wrote:
> > > >>> Hi Alex, Chris and JC,
> > > >>>
> > > >>> Please review an updated version of the patch that addresses these
> > > >>> issues.
> > > >>>
> > > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
> > > >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > >>>
> > > >>> Thanks!
> > > >>> --Daniil
> > > >>>
> > > >>>
> > > >>> On 10/12/18, 9:52 AM, "Alex Menkov"<***@oracle.com> wrote:
> > > >>>
> > > >>> Hi Daniil,
> > > >>> 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL
> > > >>> 2) wrong indent in JdbStopThreadTest.java:
> > > >>> 36 import lib.jdb.JdbCommand;
> > > >>> 37 import lib.jdb.JdbTest;
> > > >>> 3) I think it would be better to make waitForSimplePrompt
> > > >>> property of
> > > >>> JdbCommand (like JdbCommand.allowExit)
> > > >>> jdb.command(JdbCommand.run().replyIsSimplePrompt());
> > > >>> looks much clearer than
> > > >>> jdb.command(JdbCommand.run(), true);
> > > >>> 4) (TTY.java)
> > > >>> MessageOutput.lnprint("Breakpoint hit:");
> > > >>> + // Print current location and prompt if suspend policy is
> > > >>> SUSPEND_EVENT_THREAD.
> > > >>> + // In case of SUSPEND_ALL policy this is handled by
> > > >>> vmInterrupted()
> > > >>> method.
> > > >>> + if (be.request().suspendPolicy() ==
> > > >>> EventRequest.SUSPEND_EVENT_THREAD) {
> > > >>> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
> > > >>> + MessageOutput.printPrompt();
> > > >>> + }
> > > >>> We have 3 separate outputs.
> > > >>> If we have several concurrent threads, we can easy get mess of
> > > >>> outputs
> > > >>> from different threads.
> > > >>> I think it would be better to print everything in a single chunk.
> > > >>> I suppose TTY has other places with similar "non-atomic"
> > > >>> output, so
> > > >>> maybe revising TTY output should be handled by separate issue.
> > > >>> --alex
> > > >>> On 10/11/2018 22:00, Chris Plummer wrote:
> > > >>> > Hi Daniil,
> > > >>> >
> > > >>> > Can you send output from an example jdb session?
> > > >>> >
> > > >>> > Do you think maybe we should also call printCurrentLocation()
> > > >>> when the
> > > >>> > suspend policy is NONE?
> > > >>> >
> > > >>> > There's a typo in the following line. The space is on the
> > > >>> wrong side of
> > > >>> > the comma.
> > > >>> >
> > > >>> > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
> > > >>> ,bpLine));
> > > >>> >
> > > >>> > thanks,
> > > >>> >
> > > >>> > Chris
> > > >>> >
> > > >>> > On 10/11/18 8:02 PM, Daniil Titov wrote:
> > > >>> >>
> > > >>> >> Thank you, JC!
> > > >>> >>
> > > >>> >> Please review an updated version of the patch that fixes
> > > >>> newly added
> > > >>> >> test for Windows platform (now it uses system dependent line
> > > >>> >> separator string).
> > > >>> >>
> > > >>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
> > > >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
> > > >>> >>
> > > >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > >>> >>
> > > >>> >> Best regards,
> > > >>> >>
> > > >>> >> --Daniil
> > > >>> >>
> > > >>> >> *From: *JC Beyler<***@google.com>
> > > >>> >> *Date: *Thursday, October 11, 2018 at 7:17 PM
> > > >>> >> *To: *<***@oracle.com>
> > > >>> >> *Cc: *<serviceability-***@openjdk.java.net>
> > > >>> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when
> > > >>> breakpoint
> > > >>> >> is hit and suspend policy is STOP_EVENT_THREAD
> > > >>> >>
> > > >>> >> Hi Daniil,
> > > >>> >>
> > > >>> >> Looks good to me. I saw a really small nit:
> > > >>> >>
> > > >>> >>
> > > >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
> > > >>>
> > > >>> >>
> > > >>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
> > > >>>
> > > >>> >>
> > > >>> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS
> > > >>> ,bpLine));
> > > >>> >>
> > > >>> >> There is a space after the '('.
> > > >>> >>
> > > >>> >> No need to send a new webrev for that evidently :),
> > > >>> >>
> > > >>> >> Jc
> > > >>> >>
> > > >>> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
> > > >>> >> <***@oracle.com
> > > >>> <mailto:***@oracle.com>> wrote:
> > > >>> >>
> > > >>> >> Please review the change that fixes the issue with
> > > >>> missing prompt
> > > >>> >> in jdb when a breakpoint is hit and the suspend policy
> > > >>> is set to
> > > >>> >> stop the thread only.
> > > >>> >>
> > > >>> >> Webrev:
> > > >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
> > > >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
> > > >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > >>> >>
> > > >>> >> Thanks!
> > > >>> >> --Daniil
> > > >>> >>
> > > >>> >>
> > > >>> >>
> > > >>> >> --
> > > >>> >>
> > > >>> >> Thanks,
> > > >>> >>
> > > >>> >> Jc
> > > >>> >>
> > > >>> >
> > > >>>
> > > >>>
> > > >>
> > > >>
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
>
Gary Adams
2018-10-22 11:53:21 UTC
Permalink
Seems like most people are fine with the breakpoint location
for the non stopping cases, so it's OK for me too. Would it make
sense for all breakpoint locations to be displayed from BreakpointEvent().

Thanks for making the extra effort to avoid dependency on
the simple prompt matching. One thing to check with the
large reply matches - make sure the locale translated messages
do not interfere with the compiled pattern matching.
See MessageOutput.format().

On 10/19/18, 7:01 PM, Daniil Titov wrote:
> Hi Chris,
>
> Please review an updated version of the fix that makes the tests to use a custom pattern while waiting for the command to complete.
>
> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>
> Thanks!
> --Daniil
>
>
> On 10/19/18, 12:55 PM, "Chris Plummer"<***@oracle.com> wrote:
>
> On 10/19/18 9:47 AM, Daniil Titov wrote:
> > Hi Gary and Chris,
> >
> > I am resending the previous email since the table in that email got corrupted.
> >
> > Below is what output jdb prints when a breakpoint is hit depending on what suspended policy is used:
> >
> > The current behavior.
> > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed
> > SUSPEND_EVENT_THREAD: Prompt is not printed, location is not printed
> > SUSPEND_NONE: Prompt is not printed, location is not printed
> >
> > The fix changes this behavior as the following:
> >
> > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed
> > SUSPEND_EVENT_THREAD: Prompt is printed ( "> "), location is printed
> > SUSPEND_NONE: Prompt is printed ( "> "), location is printed
> I'm still in favor of this fix.
> >
> >
> > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"?
> >
> > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt "> " (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here...
> Maybe we need a version of command() that takes a pattern to look for
> other than the prompt.
>
> Chris
> >
> >
> > Thanks!
> > --Daniil
> >
> > On 10/19/18, 9:27 AM, "Daniil Titov"<***@oracle.com> wrote:
> >
> > Hi Gary and Chris,
> >
> > Below is the table that shows what jdb output is printed when a breakpoint is hit depending on what suspended policy is used:
> >
> > SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED
> > --------------------------------------- |---------------------------|--------------------------
> > SUSPEND_ALL. | yes, e.g. "main[1]" | yes
> > --------------------------------------- |-------------------------- |--------------------------
> > SUSPEND_EVENT_THREAD | no | no
> > ----------------------------------------|------------------------ --|--------------------------
> > SUSPEND_ALL. | no | no
> >
> >
> > The fix changes this behavior as the following:
> >
> > SUSPEND POLICY | PROMPT PRINTED. | LOCATION PRINTED
> > --------------------------------------- |----------------------------|--------------------------
> > SUSPEND_ALL. | yes , e.g. "main[1]" | yes
> > --------------------------------------- |----------------------------|--------------------------
> > SUSPEND_EVENT_THREAD | yes , ">" | yes
> > ----------------------------------------|--------------------------- |--------------------------
> > SUSPEND_ALL. | yes, ">". | yes
> >
> > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"?
> >
> > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt "> " (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here...
> >
> >
> > Thanks!
> >
> > Best regards,
> > Daniil
> >
> >
> >
> > On 10/19/18, 12:54 AM, "***@oracle.com"<***@oracle.com> wrote:
> >
> > It's not clear to me if the omitted location information for the non
> > stopping
> > cases was intentional or not. It may be sufficient to know that the
> > event fired
> > without the extra information.
> >
> > I don't think a settable prompt is required either. There are plenty of
> > jdb commands that
> > could be used with the wait for message in tests that need to
> > synchronize at a specific
> > point in the test sequence.
> >
> > I don't think we see wait for simple prompt in any of the tests, because it
> > is not reliable enough.
> >
> > On 10/18/18 11:53 AM, Daniil Titov wrote:
> > > Hi Gary,
> > >
> > > Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach?
> > >
> > > Thanks!
> > >
> > > Best regards,
> > > Daniil
> > >
> > >
> > >
> > > On 10/18/18, 4:09 AM, "Gary Adams"<***@oracle.com> wrote:
> > >
> > > I'm not certain that we should be printing locations or prompts for
> > > events when the vm has not been suspended. This looks OK for the
> > > simple test case we are working on here, but in real life there may
> > > be a lot more output produced.
> > >
> > > The user has to select a specific thread before additional commands
> > > can be performed in the correct context. e.g. threads, thread n, where, ...
> > > So the information is available to the user. It doesn't have to be
> > > produced at the time the event is processed.
> > >
> > > I'm uncomfortable putting too much trust in waiting for the simple prompt,
> > > because there is too great a chance of false positives on such a small
> > > marker.
> > >
> > >
> > > On 10/17/18, 8:50 PM, Daniil Titov wrote:
> > > > Hi Chris, Alex and JC,
> > > >
> > > > I created a separate issue to deal with "non-atomic" jdb output at https://bugs.openjdk.java.net/browse/JDK-8212626 .
> > > >
> > > > Please review an updated fix that includes the changes Alex suggested.
> > > >
> > > > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.04
> > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > >
> > > > Thanks!
> > > > --Daniil
> > > >
> > > >
> > > > On 10/17/18, 5:06 PM, "Daniil Titov"<***@oracle.com> wrote:
> > > >
> > > > Hi Chris,
> > > >
> > > > The previous email was accidentally fired before I managed to type anything in. Sorry for confusion.
> > > >
> > > > Jdb constantly reads new commands from System.in despite whether the breakpoint is hit and/or the prompt is printed.
> > > >
> > > > cat -n src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
> > > >
> > > > 786 // Process interactive commands.
> > > > 787 MessageOutput.printPrompt();
> > > > 788 while (true) {
> > > > 789 String ln = in.readLine();
> > > > 790 if (ln == null) {
> > > > 791 /*
> > > > 792 * Jdb is being shutdown because debuggee exited, ignore any 'null'
> > > > 793 * returned by readLine() during shutdown. JDK-8154144.
> > > > 794 */
> > > > 795 if (!isShuttingDown()) {
> > > > 796 MessageOutput.println("Input stream closed.");
> > > > 797 }
> > > > 798 ln = "quit";
> > > > 799 }
> > > > 800
> > > > 801 if (ln.startsWith("!!")&& lastLine != null) {
> > > > 802 ln = lastLine + ln.substring(2);
> > > > 803 MessageOutput.printDirectln(ln);// Special case: use printDirectln()
> > > > 804 }
> > > > 805
> > > > 806 StringTokenizer t = new StringTokenizer(ln);
> > > > 807 if (t.hasMoreTokens()) {
> > > > 808 lastLine = ln;
> > > > 809 executeCommand(t);
> > > > 810 } else {
> > > > 811 MessageOutput.printPrompt();
> > > > 812 }
> > > > 813 }
> > > > 814 } catch (VMDisconnectedException e) {
> > > > 815 handler.handleDisconnectedException();
> > > > 816 }
> > > >
> > > > Below is a sample debug session for the following test class that sends commands "threads" and "quit"
> > > > 1 public class LoopTest {
> > > > 2 public static void main(String[] args) throws Exception {
> > > > 3 Thread thread = Thread.currentThread();
> > > > 4 while(true) {
> > > > 5 print(thread);
> > > > 6 Thread.sleep(5000);
> > > > 7 }
> > > > 8 }
> > > > 9
> > > > 10 public static void print(Object obj) {
> > > > 11 //System.out.println(obj);
> > > > 12 }
> > > > 13 }
> > > >
> > > > datitov-mac:work datitov$ ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest
> > > > Initializing jdb ...
> > > > > stop go at LoopTest:6
> > > > Deferring breakpoint LoopTest:6.
> > > > It will be set after the class is loaded.
> > > > > run
> > > > run LoopTest
> > > > Set uncaught java.lang.Throwable
> > > > Set deferred uncaught java.lang.Throwable
> > > > >
> > > > VM Started: Set deferred breakpoint LoopTest:6
> > > >
> > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > 6 Thread.sleep(5000);
> > > >
> > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > 6 Thread.sleep(5000);
> > > > 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 sleeping
> > > > Group InnocuousThreadGroup:
> > > > (jdk.internal.misc.InnocuousThread)0x197 Common-Cleaner cond. waiting
> > > > >
> > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > 6 Thread.sleep(5000);
> > > >
> > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > 6 Thread.sleep(5000);
> > > > quit
> > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > 6 Thread.sleep(5000);
> > > >
> > > > datitov-mac:work datitov$
> > > >
> > > > I think we could print a simple prompt in this case as Alex suggested.
> > > >
> > > > Best regards,
> > > > Daniil
> > > >
> > > > On 10/17/18, 3:52 PM, "Chris Plummer"<***@oracle.com> wrote:
> > > >
> > > > What is the jdb state for a breakpoint with SUSPEND_NONE? Can you
> > > > actually type in commands even though no threads are suspended?
> > > >
> > > > Chris
> > > >
> > > > On 10/17/18 3:31 PM, Alex Menkov wrote:
> > > > > Hi Daniil, Chris,
> > > > >
> > > > > As far as I understand, the fix does not completely fixes all
> > > > > "non-atomic" output issues (at least TTY.executeCommand still prints
> > > > > prompt separately), so I agree that handle it as separate issue would
> > > > > be better.
> > > > > Unfortunately I don't know Gary's ideas for the issue.
> > > > >
> > > > > About the fix for print prompt:
> > > > > 1) TTY.java:
> > > > > + // Print current location if suspend policy is SUSPEND_NONE
> > > > > I suppose you mean "Print breakpoint location"
> > > > >
> > > > > 2) Does it make sense to use printCurrentLocation for
> > > > > SUSPEND_EVENT_THREAD?
> > > > > Is it expected to print something different from printBreakpointLocation?
> > > > >
> > > > > 3) I don't quite understand why we don't print simple prompt for
> > > > > SUSPEND_NONE. IIUC jdb can accept new command in both
> > > > > SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb
> > > > > waits for next command, right?)
> > > > >
> > > > > 4) JdbStopThreadTest.java
> > > > > New line line in Java regexp is "\\R"
> > > > >
> > > > > --alex
> > > > >
> > > > > On 10/17/2018 10:47, Chris Plummer wrote:
> > > > >> Hi Alex,
> > > > >>
> > > > >> I think the tty buffering should be a separate bug fix, and I'd also
> > > > >> like input from Gary on it since he had tried something similar at
> > > > >> one point. It should probably also include a multithread test to
> > > > >> prove the fix is working (after first getting the test to fail
> > > > >> without the changes).
> > > > >>
> > > > >> thanks,
> > > > >>
> > > > >> Chris
> > > > >>
> > > > >> On 10/16/18 8:59 PM, Daniil Titov wrote:
> > > > >>> Hi Alex, Chris and JC,
> > > > >>>
> > > > >>> Please review an updated version of the patch that addresses these
> > > > >>> issues.
> > > > >>>
> > > > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
> > > > >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > >>>
> > > > >>> Thanks!
> > > > >>> --Daniil
> > > > >>>
> > > > >>>
> > > > >>> On 10/12/18, 9:52 AM, "Alex Menkov"<***@oracle.com> wrote:
> > > > >>>
> > > > >>> Hi Daniil,
> > > > >>> 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL
> > > > >>> 2) wrong indent in JdbStopThreadTest.java:
> > > > >>> 36 import lib.jdb.JdbCommand;
> > > > >>> 37 import lib.jdb.JdbTest;
> > > > >>> 3) I think it would be better to make waitForSimplePrompt
> > > > >>> property of
> > > > >>> JdbCommand (like JdbCommand.allowExit)
> > > > >>> jdb.command(JdbCommand.run().replyIsSimplePrompt());
> > > > >>> looks much clearer than
> > > > >>> jdb.command(JdbCommand.run(), true);
> > > > >>> 4) (TTY.java)
> > > > >>> MessageOutput.lnprint("Breakpoint hit:");
> > > > >>> + // Print current location and prompt if suspend policy is
> > > > >>> SUSPEND_EVENT_THREAD.
> > > > >>> + // In case of SUSPEND_ALL policy this is handled by
> > > > >>> vmInterrupted()
> > > > >>> method.
> > > > >>> + if (be.request().suspendPolicy() ==
> > > > >>> EventRequest.SUSPEND_EVENT_THREAD) {
> > > > >>> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
> > > > >>> + MessageOutput.printPrompt();
> > > > >>> + }
> > > > >>> We have 3 separate outputs.
> > > > >>> If we have several concurrent threads, we can easy get mess of
> > > > >>> outputs
> > > > >>> from different threads.
> > > > >>> I think it would be better to print everything in a single chunk.
> > > > >>> I suppose TTY has other places with similar "non-atomic"
> > > > >>> output, so
> > > > >>> maybe revising TTY output should be handled by separate issue.
> > > > >>> --alex
> > > > >>> On 10/11/2018 22:00, Chris Plummer wrote:
> > > > >>> > Hi Daniil,
> > > > >>> >
> > > > >>> > Can you send output from an example jdb session?
> > > > >>> >
> > > > >>> > Do you think maybe we should also call printCurrentLocation()
> > > > >>> when the
> > > > >>> > suspend policy is NONE?
> > > > >>> >
> > > > >>> > There's a typo in the following line. The space is on the
> > > > >>> wrong side of
> > > > >>> > the comma.
> > > > >>> >
> > > > >>> > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
> > > > >>> ,bpLine));
> > > > >>> >
> > > > >>> > thanks,
> > > > >>> >
> > > > >>> > Chris
> > > > >>> >
> > > > >>> > On 10/11/18 8:02 PM, Daniil Titov wrote:
> > > > >>> >>
> > > > >>> >> Thank you, JC!
> > > > >>> >>
> > > > >>> >> Please review an updated version of the patch that fixes
> > > > >>> newly added
> > > > >>> >> test for Windows platform (now it uses system dependent line
> > > > >>> >> separator string).
> > > > >>> >>
> > > > >>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
> > > > >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
> > > > >>> >>
> > > > >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > >>> >>
> > > > >>> >> Best regards,
> > > > >>> >>
> > > > >>> >> --Daniil
> > > > >>> >>
> > > > >>> >> *From: *JC Beyler<***@google.com>
> > > > >>> >> *Date: *Thursday, October 11, 2018 at 7:17 PM
> > > > >>> >> *To: *<***@oracle.com>
> > > > >>> >> *Cc: *<serviceability-***@openjdk.java.net>
> > > > >>> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when
> > > > >>> breakpoint
> > > > >>> >> is hit and suspend policy is STOP_EVENT_THREAD
> > > > >>> >>
> > > > >>> >> Hi Daniil,
> > > > >>> >>
> > > > >>> >> Looks good to me. I saw a really small nit:
> > > > >>> >>
> > > > >>> >>
> > > > >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
> > > > >>>
> > > > >>> >>
> > > > >>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
> > > > >>>
> > > > >>> >>
> > > > >>> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS
> > > > >>> ,bpLine));
> > > > >>> >>
> > > > >>> >> There is a space after the '('.
> > > > >>> >>
> > > > >>> >> No need to send a new webrev for that evidently :),
> > > > >>> >>
> > > > >>> >> Jc
> > > > >>> >>
> > > > >>> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
> > > > >>> >> <***@oracle.com
> > > > >>> <mailto:***@oracle.com>> wrote:
> > > > >>> >>
> > > > >>> >> Please review the change that fixes the issue with
> > > > >>> missing prompt
> > > > >>> >> in jdb when a breakpoint is hit and the suspend policy
> > > > >>> is set to
> > > > >>> >> stop the thread only.
> > > > >>> >>
> > > > >>> >> Webrev:
> > > > >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
> > > > >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
> > > > >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > >>> >>
> > > > >>> >> Thanks!
> > > > >>> >> --Daniil
> > > > >>> >>
> > > > >>> >>
> > > > >>> >>
> > > > >>> >> --
> > > > >>> >>
> > > > >>> >> Thanks,
> > > > >>> >>
> > > > >>> >> Jc
> > > > >>> >>
> > > > >>> >
> > > > >>>
> > > > >>>
> > > > >>
> > > > >>
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>
Daniil Titov
2018-10-22 21:54:01 UTC
Permalink
Hi Gary,

As I see currently multiple tests already use the patterns that in fact are localized messages, e.g. for 'Breakpoint hit' the following tests expect to find this message in the JDB output.

grep -rn 'Breakpoint hit' open/test/jdk/com/sun/jdi/
open/test/jdk/com/sun/jdi//JdbMissStep.java:82: .shouldContain("Breakpoint hit");
open/test/jdk/com/sun/jdi//JdbExprTest.java:73: .shouldContain("Breakpoint hit");
open/test/jdk/com/sun/jdi//JdbVarargsTest.java:98: .shouldMatch("Breakpoint hit:.*varString\\(\\)");
open/test/jdk/com/sun/jdi//lib/jdb/Jdb.java:81: public static final String BREAKPOINT_HIT = "Breakpoint hit:";
open/test/jdk/com/sun/jdi//JdbMethodExitTest.java:204: .shouldContain("Breakpoint hit");
open/test/jdk/com/sun/jdi//JdbMethodExitTest.java:303: .shouldContain("Breakpoint hit");

If we really want to get rid of this (e.g. for the cases when these tests are run with non-default English locale), I would suggest to file a separate issue for that rather than addressing it in the current fix.

Best regards,
Daniil

On 10/22/18, 4:50 AM, "Gary Adams" <***@oracle.com> wrote:


Thanks for making the extra effort to avoid dependency on
the simple prompt matching. One thing to check with the
large reply matches - make sure the locale translated messages
do not interfere with the compiled pattern matching.
See MessageOutput.format().

On 10/19/18, 7:01 PM, Daniil Titov wrote:
> Hi Chris,
>
> Please review an updated version of the fix that makes the tests to use a custom pattern while waiting for the command to complete.
>
> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>
> Thanks!
> --Daniil
>
>
> On 10/19/18, 12:55 PM, "Chris Plummer"<***@oracle.com> wrote:
>
> On 10/19/18 9:47 AM, Daniil Titov wrote:
> > Hi Gary and Chris,
> >
> > I am resending the previous email since the table in that email got corrupted.
> >
> > Below is what output jdb prints when a breakpoint is hit depending on what suspended policy is used:
> >
> > The current behavior.
> > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed
> > SUSPEND_EVENT_THREAD: Prompt is not printed, location is not printed
> > SUSPEND_NONE: Prompt is not printed, location is not printed
> >
> > The fix changes this behavior as the following:
> >
> > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed
> > SUSPEND_EVENT_THREAD: Prompt is printed ( "> "), location is printed
> > SUSPEND_NONE: Prompt is printed ( "> "), location is printed
> I'm still in favor of this fix.
> >
> >
> > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"?
> >
> > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt "> " (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here...
> Maybe we need a version of command() that takes a pattern to look for
> other than the prompt.
>
> Chris
> >
> >
> > Thanks!
> > --Daniil
> >
> > On 10/19/18, 9:27 AM, "Daniil Titov"<***@oracle.com> wrote:
> >
> > Hi Gary and Chris,
> >
> > Below is the table that shows what jdb output is printed when a breakpoint is hit depending on what suspended policy is used:
> >
> > SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED
> > --------------------------------------- |---------------------------|--------------------------
> > SUSPEND_ALL. | yes, e.g. "main[1]" | yes
> > --------------------------------------- |-------------------------- |--------------------------
> > SUSPEND_EVENT_THREAD | no | no
> > ----------------------------------------|------------------------ --|--------------------------
> > SUSPEND_ALL. | no | no
> >
> >
> > The fix changes this behavior as the following:
> >
> > SUSPEND POLICY | PROMPT PRINTED. | LOCATION PRINTED
> > --------------------------------------- |----------------------------|--------------------------
> > SUSPEND_ALL. | yes , e.g. "main[1]" | yes
> > --------------------------------------- |----------------------------|--------------------------
> > SUSPEND_EVENT_THREAD | yes , ">" | yes
> > ----------------------------------------|--------------------------- |--------------------------
> > SUSPEND_ALL. | yes, ">". | yes
> >
> > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"?
> >
> > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt "> " (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here...
> >
> >
> > Thanks!
> >
> > Best regards,
> > Daniil
> >
> >
> >
> > On 10/19/18, 12:54 AM, "***@oracle.com"<***@oracle.com> wrote:
> >
> > It's not clear to me if the omitted location information for the non
> > stopping
> > cases was intentional or not. It may be sufficient to know that the
> > event fired
> > without the extra information.
> >
> > I don't think a settable prompt is required either. There are plenty of
> > jdb commands that
> > could be used with the wait for message in tests that need to
> > synchronize at a specific
> > point in the test sequence.
> >
> > I don't think we see wait for simple prompt in any of the tests, because it
> > is not reliable enough.
> >
> > On 10/18/18 11:53 AM, Daniil Titov wrote:
> > > Hi Gary,
> > >
> > > Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach?
> > >
> > > Thanks!
> > >
> > > Best regards,
> > > Daniil
> > >
> > >
> > >
> > > On 10/18/18, 4:09 AM, "Gary Adams"<***@oracle.com> wrote:
> > >
> > > I'm not certain that we should be printing locations or prompts for
> > > events when the vm has not been suspended. This looks OK for the
> > > simple test case we are working on here, but in real life there may
> > > be a lot more output produced.
> > >
> > > The user has to select a specific thread before additional commands
> > > can be performed in the correct context. e.g. threads, thread n, where, ...
> > > So the information is available to the user. It doesn't have to be
> > > produced at the time the event is processed.
> > >
> > > I'm uncomfortable putting too much trust in waiting for the simple prompt,
> > > because there is too great a chance of false positives on such a small
> > > marker.
> > >
> > >
> > > On 10/17/18, 8:50 PM, Daniil Titov wrote:
> > > > Hi Chris, Alex and JC,
> > > >
> > > > I created a separate issue to deal with "non-atomic" jdb output at https://bugs.openjdk.java.net/browse/JDK-8212626 .
> > > >
> > > > Please review an updated fix that includes the changes Alex suggested.
> > > >
> > > > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.04
> > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > >
> > > > Thanks!
> > > > --Daniil
> > > >
> > > >
> > > > On 10/17/18, 5:06 PM, "Daniil Titov"<***@oracle.com> wrote:
> > > >
> > > > Hi Chris,
> > > >
> > > > The previous email was accidentally fired before I managed to type anything in. Sorry for confusion.
> > > >
> > > > Jdb constantly reads new commands from System.in despite whether the breakpoint is hit and/or the prompt is printed.
> > > >
> > > > cat -n src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
> > > >
> > > > 786 // Process interactive commands.
> > > > 787 MessageOutput.printPrompt();
> > > > 788 while (true) {
> > > > 789 String ln = in.readLine();
> > > > 790 if (ln == null) {
> > > > 791 /*
> > > > 792 * Jdb is being shutdown because debuggee exited, ignore any 'null'
> > > > 793 * returned by readLine() during shutdown. JDK-8154144.
> > > > 794 */
> > > > 795 if (!isShuttingDown()) {
> > > > 796 MessageOutput.println("Input stream closed.");
> > > > 797 }
> > > > 798 ln = "quit";
> > > > 799 }
> > > > 800
> > > > 801 if (ln.startsWith("!!")&& lastLine != null) {
> > > > 802 ln = lastLine + ln.substring(2);
> > > > 803 MessageOutput.printDirectln(ln);// Special case: use printDirectln()
> > > > 804 }
> > > > 805
> > > > 806 StringTokenizer t = new StringTokenizer(ln);
> > > > 807 if (t.hasMoreTokens()) {
> > > > 808 lastLine = ln;
> > > > 809 executeCommand(t);
> > > > 810 } else {
> > > > 811 MessageOutput.printPrompt();
> > > > 812 }
> > > > 813 }
> > > > 814 } catch (VMDisconnectedException e) {
> > > > 815 handler.handleDisconnectedException();
> > > > 816 }
> > > >
> > > > Below is a sample debug session for the following test class that sends commands "threads" and "quit"
> > > > 1 public class LoopTest {
> > > > 2 public static void main(String[] args) throws Exception {
> > > > 3 Thread thread = Thread.currentThread();
> > > > 4 while(true) {
> > > > 5 print(thread);
> > > > 6 Thread.sleep(5000);
> > > > 7 }
> > > > 8 }
> > > > 9
> > > > 10 public static void print(Object obj) {
> > > > 11 //System.out.println(obj);
> > > > 12 }
> > > > 13 }
> > > >
> > > > datitov-mac:work datitov$ ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest
> > > > Initializing jdb ...
> > > > > stop go at LoopTest:6
> > > > Deferring breakpoint LoopTest:6.
> > > > It will be set after the class is loaded.
> > > > > run
> > > > run LoopTest
> > > > Set uncaught java.lang.Throwable
> > > > Set deferred uncaught java.lang.Throwable
> > > > >
> > > > VM Started: Set deferred breakpoint LoopTest:6
> > > >
> > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > 6 Thread.sleep(5000);
> > > >
> > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > 6 Thread.sleep(5000);
> > > > 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 sleeping
> > > > Group InnocuousThreadGroup:
> > > > (jdk.internal.misc.InnocuousThread)0x197 Common-Cleaner cond. waiting
> > > > >
> > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > 6 Thread.sleep(5000);
> > > >
> > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > 6 Thread.sleep(5000);
> > > > quit
> > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > 6 Thread.sleep(5000);
> > > >
> > > > datitov-mac:work datitov$
> > > >
> > > > I think we could print a simple prompt in this case as Alex suggested.
> > > >
> > > > Best regards,
> > > > Daniil
> > > >
> > > > On 10/17/18, 3:52 PM, "Chris Plummer"<***@oracle.com> wrote:
> > > >
> > > > What is the jdb state for a breakpoint with SUSPEND_NONE? Can you
> > > > actually type in commands even though no threads are suspended?
> > > >
> > > > Chris
> > > >
> > > > On 10/17/18 3:31 PM, Alex Menkov wrote:
> > > > > Hi Daniil, Chris,
> > > > >
> > > > > As far as I understand, the fix does not completely fixes all
> > > > > "non-atomic" output issues (at least TTY.executeCommand still prints
> > > > > prompt separately), so I agree that handle it as separate issue would
> > > > > be better.
> > > > > Unfortunately I don't know Gary's ideas for the issue.
> > > > >
> > > > > About the fix for print prompt:
> > > > > 1) TTY.java:
> > > > > + // Print current location if suspend policy is SUSPEND_NONE
> > > > > I suppose you mean "Print breakpoint location"
> > > > >
> > > > > 2) Does it make sense to use printCurrentLocation for
> > > > > SUSPEND_EVENT_THREAD?
> > > > > Is it expected to print something different from printBreakpointLocation?
> > > > >
> > > > > 3) I don't quite understand why we don't print simple prompt for
> > > > > SUSPEND_NONE. IIUC jdb can accept new command in both
> > > > > SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb
> > > > > waits for next command, right?)
> > > > >
> > > > > 4) JdbStopThreadTest.java
> > > > > New line line in Java regexp is "\\R"
> > > > >
> > > > > --alex
> > > > >
> > > > > On 10/17/2018 10:47, Chris Plummer wrote:
> > > > >> Hi Alex,
> > > > >>
> > > > >> I think the tty buffering should be a separate bug fix, and I'd also
> > > > >> like input from Gary on it since he had tried something similar at
> > > > >> one point. It should probably also include a multithread test to
> > > > >> prove the fix is working (after first getting the test to fail
> > > > >> without the changes).
> > > > >>
> > > > >> thanks,
> > > > >>
> > > > >> Chris
> > > > >>
> > > > >> On 10/16/18 8:59 PM, Daniil Titov wrote:
> > > > >>> Hi Alex, Chris and JC,
> > > > >>>
> > > > >>> Please review an updated version of the patch that addresses these
> > > > >>> issues.
> > > > >>>
> > > > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
> > > > >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > >>>
> > > > >>> Thanks!
> > > > >>> --Daniil
> > > > >>>
> > > > >>>
> > > > >>> On 10/12/18, 9:52 AM, "Alex Menkov"<***@oracle.com> wrote:
> > > > >>>
> > > > >>> Hi Daniil,
> > > > >>> 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL
> > > > >>> 2) wrong indent in JdbStopThreadTest.java:
> > > > >>> 36 import lib.jdb.JdbCommand;
> > > > >>> 37 import lib.jdb.JdbTest;
> > > > >>> 3) I think it would be better to make waitForSimplePrompt
> > > > >>> property of
> > > > >>> JdbCommand (like JdbCommand.allowExit)
> > > > >>> jdb.command(JdbCommand.run().replyIsSimplePrompt());
> > > > >>> looks much clearer than
> > > > >>> jdb.command(JdbCommand.run(), true);
> > > > >>> 4) (TTY.java)
> > > > >>> MessageOutput.lnprint("Breakpoint hit:");
> > > > >>> + // Print current location and prompt if suspend policy is
> > > > >>> SUSPEND_EVENT_THREAD.
> > > > >>> + // In case of SUSPEND_ALL policy this is handled by
> > > > >>> vmInterrupted()
> > > > >>> method.
> > > > >>> + if (be.request().suspendPolicy() ==
> > > > >>> EventRequest.SUSPEND_EVENT_THREAD) {
> > > > >>> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
> > > > >>> + MessageOutput.printPrompt();
> > > > >>> + }
> > > > >>> We have 3 separate outputs.
> > > > >>> If we have several concurrent threads, we can easy get mess of
> > > > >>> outputs
> > > > >>> from different threads.
> > > > >>> I think it would be better to print everything in a single chunk.
> > > > >>> I suppose TTY has other places with similar "non-atomic"
> > > > >>> output, so
> > > > >>> maybe revising TTY output should be handled by separate issue.
> > > > >>> --alex
> > > > >>> On 10/11/2018 22:00, Chris Plummer wrote:
> > > > >>> > Hi Daniil,
> > > > >>> >
> > > > >>> > Can you send output from an example jdb session?
> > > > >>> >
> > > > >>> > Do you think maybe we should also call printCurrentLocation()
> > > > >>> when the
> > > > >>> > suspend policy is NONE?
> > > > >>> >
> > > > >>> > There's a typo in the following line. The space is on the
> > > > >>> wrong side of
> > > > >>> > the comma.
> > > > >>> >
> > > > >>> > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
> > > > >>> ,bpLine));
> > > > >>> >
> > > > >>> > thanks,
> > > > >>> >
> > > > >>> > Chris
> > > > >>> >
> > > > >>> > On 10/11/18 8:02 PM, Daniil Titov wrote:
> > > > >>> >>
> > > > >>> >> Thank you, JC!
> > > > >>> >>
> > > > >>> >> Please review an updated version of the patch that fixes
> > > > >>> newly added
> > > > >>> >> test for Windows platform (now it uses system dependent line
> > > > >>> >> separator string).
> > > > >>> >>
> > > > >>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
> > > > >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
> > > > >>> >>
> > > > >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > >>> >>
> > > > >>> >> Best regards,
> > > > >>> >>
> > > > >>> >> --Daniil
> > > > >>> >>
> > > > >>> >> *From: *JC Beyler<***@google.com>
> > > > >>> >> *Date: *Thursday, October 11, 2018 at 7:17 PM
> > > > >>> >> *To: *<***@oracle.com>
> > > > >>> >> *Cc: *<serviceability-***@openjdk.java.net>
> > > > >>> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when
> > > > >>> breakpoint
> > > > >>> >> is hit and suspend policy is STOP_EVENT_THREAD
> > > > >>> >>
> > > > >>> >> Hi Daniil,
> > > > >>> >>
> > > > >>> >> Looks good to me. I saw a really small nit:
> > > > >>> >>
> > > > >>> >>
> > > > >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
> > > > >>>
> > > > >>> >>
> > > > >>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
> > > > >>>
> > > > >>> >>
> > > > >>> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS
> > > > >>> ,bpLine));
> > > > >>> >>
> > > > >>> >> There is a space after the '('.
> > > > >>> >>
> > > > >>> >> No need to send a new webrev for that evidently :),
> > > > >>> >>
> > > > >>> >> Jc
> > > > >>> >>
> > > > >>> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
> > > > >>> >> <***@oracle.com
> > > > >>> <mailto:***@oracle.com>> wrote:
> > > > >>> >>
> > > > >>> >> Please review the change that fixes the issue with
> > > > >>> missing prompt
> > > > >>> >> in jdb when a breakpoint is hit and the suspend policy
> > > > >>> is set to
> > > > >>> >> stop the thread only.
> > > > >>> >>
> > > > >>> >> Webrev:
> > > > >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
> > > > >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
> > > > >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > >>> >>
> > > > >>> >> Thanks!
> > > > >>> >> --Daniil
> > > > >>> >>
> > > > >>> >>
> > > > >>> >>
> > > > >>> >> --
> > > > >>> >>
> > > > >>> >> Thanks,
> > > > >>> >>
> > > > >>> >> Jc
> > > > >>> >>
> > > > >>> >
> > > > >>>
> > > > >>>
> > > > >>
> > > > >>
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>
Gary Adams
2018-10-23 12:40:21 UTC
Permalink
Thanks for checking.

I think it is Ok if the tests are only supported in the default locale.

I think that restriction should be documented somewhere.
If there is a simple way to check at runtime, we could
issue a warning message.

Definitely out of scope for this specific changeset.
I wonder if this was discussed when the initial
alternate locale messages were introduced.

On 10/22/18, 5:54 PM, Daniil Titov wrote:
> Hi Gary,
>
> As I see currently multiple tests already use the patterns that in fact are localized messages, e.g. for 'Breakpoint hit' the following tests expect to find this message in the JDB output.
>
> grep -rn 'Breakpoint hit' open/test/jdk/com/sun/jdi/
> open/test/jdk/com/sun/jdi//JdbMissStep.java:82: .shouldContain("Breakpoint hit");
> open/test/jdk/com/sun/jdi//JdbExprTest.java:73: .shouldContain("Breakpoint hit");
> open/test/jdk/com/sun/jdi//JdbVarargsTest.java:98: .shouldMatch("Breakpoint hit:.*varString\\(\\)");
> open/test/jdk/com/sun/jdi//lib/jdb/Jdb.java:81: public static final String BREAKPOINT_HIT = "Breakpoint hit:";
> open/test/jdk/com/sun/jdi//JdbMethodExitTest.java:204: .shouldContain("Breakpoint hit");
> open/test/jdk/com/sun/jdi//JdbMethodExitTest.java:303: .shouldContain("Breakpoint hit");
> 
> If we really want to get rid of this (e.g. for the cases when these tests are run with non-default English locale), I would suggest to file a separate issue for that rather than addressing it in the current fix.
>
> Best regards,
> Daniil
>
> On 10/22/18, 4:50 AM, "Gary Adams"<***@oracle.com> wrote:
>
>
> Thanks for making the extra effort to avoid dependency on
> the simple prompt matching. One thing to check with the
> large reply matches - make sure the locale translated messages
> do not interfere with the compiled pattern matching.
> See MessageOutput.format().
>
> On 10/19/18, 7:01 PM, Daniil Titov wrote:
> > Hi Chris,
> >
> > Please review an updated version of the fix that makes the tests to use a custom pattern while waiting for the command to complete.
> >
> > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/
> > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> >
> > Thanks!
> > --Daniil
> >
> >
> > On 10/19/18, 12:55 PM, "Chris Plummer"<***@oracle.com> wrote:
> >
> > On 10/19/18 9:47 AM, Daniil Titov wrote:
> > > Hi Gary and Chris,
> > >
> > > I am resending the previous email since the table in that email got corrupted.
> > >
> > > Below is what output jdb prints when a breakpoint is hit depending on what suspended policy is used:
> > >
> > > The current behavior.
> > > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed
> > > SUSPEND_EVENT_THREAD: Prompt is not printed, location is not printed
> > > SUSPEND_NONE: Prompt is not printed, location is not printed
> > >
> > > The fix changes this behavior as the following:
> > >
> > > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed
> > > SUSPEND_EVENT_THREAD: Prompt is printed ( "> "), location is printed
> > > SUSPEND_NONE: Prompt is printed ( "> "), location is printed
> > I'm still in favor of this fix.
> > >
> > >
> > > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"?
> > >
> > > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt "> " (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here...
> > Maybe we need a version of command() that takes a pattern to look for
> > other than the prompt.
> >
> > Chris
> > >
> > >
> > > Thanks!
> > > --Daniil
> > >
> > > On 10/19/18, 9:27 AM, "Daniil Titov"<***@oracle.com> wrote:
> > >
> > > Hi Gary and Chris,
> > >
> > > Below is the table that shows what jdb output is printed when a breakpoint is hit depending on what suspended policy is used:
> > >
> > > SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED
> > > --------------------------------------- |---------------------------|--------------------------
> > > SUSPEND_ALL. | yes, e.g. "main[1]" | yes
> > > --------------------------------------- |-------------------------- |--------------------------
> > > SUSPEND_EVENT_THREAD | no | no
> > > ----------------------------------------|------------------------ --|--------------------------
> > > SUSPEND_ALL. | no | no
> > >
> > >
> > > The fix changes this behavior as the following:
> > >
> > > SUSPEND POLICY | PROMPT PRINTED. | LOCATION PRINTED
> > > --------------------------------------- |----------------------------|--------------------------
> > > SUSPEND_ALL. | yes , e.g. "main[1]" | yes
> > > --------------------------------------- |----------------------------|--------------------------
> > > SUSPEND_EVENT_THREAD | yes , ">" | yes
> > > ----------------------------------------|--------------------------- |--------------------------
> > > SUSPEND_ALL. | yes, ">". | yes
> > >
> > > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"?
> > >
> > > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt "> " (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here...
> > >
> > >
> > > Thanks!
> > >
> > > Best regards,
> > > Daniil
> > >
> > >
> > >
> > > On 10/19/18, 12:54 AM, "***@oracle.com"<***@oracle.com> wrote:
> > >
> > > It's not clear to me if the omitted location information for the non
> > > stopping
> > > cases was intentional or not. It may be sufficient to know that the
> > > event fired
> > > without the extra information.
> > >
> > > I don't think a settable prompt is required either. There are plenty of
> > > jdb commands that
> > > could be used with the wait for message in tests that need to
> > > synchronize at a specific
> > > point in the test sequence.
> > >
> > > I don't think we see wait for simple prompt in any of the tests, because it
> > > is not reliable enough.
> > >
> > > On 10/18/18 11:53 AM, Daniil Titov wrote:
> > > > Hi Gary,
> > > >
> > > > Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach?
> > > >
> > > > Thanks!
> > > >
> > > > Best regards,
> > > > Daniil
> > > >
> > > >
> > > >
> > > > On 10/18/18, 4:09 AM, "Gary Adams"<***@oracle.com> wrote:
> > > >
> > > > I'm not certain that we should be printing locations or prompts for
> > > > events when the vm has not been suspended. This looks OK for the
> > > > simple test case we are working on here, but in real life there may
> > > > be a lot more output produced.
> > > >
> > > > The user has to select a specific thread before additional commands
> > > > can be performed in the correct context. e.g. threads, thread n, where, ...
> > > > So the information is available to the user. It doesn't have to be
> > > > produced at the time the event is processed.
> > > >
> > > > I'm uncomfortable putting too much trust in waiting for the simple prompt,
> > > > because there is too great a chance of false positives on such a small
> > > > marker.
> > > >
> > > >
> > > > On 10/17/18, 8:50 PM, Daniil Titov wrote:
> > > > > Hi Chris, Alex and JC,
> > > > >
> > > > > I created a separate issue to deal with "non-atomic" jdb output at https://bugs.openjdk.java.net/browse/JDK-8212626 .
> > > > >
> > > > > Please review an updated fix that includes the changes Alex suggested.
> > > > >
> > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.04
> > > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > >
> > > > > Thanks!
> > > > > --Daniil
> > > > >
> > > > >
> > > > > On 10/17/18, 5:06 PM, "Daniil Titov"<***@oracle.com> wrote:
> > > > >
> > > > > Hi Chris,
> > > > >
> > > > > The previous email was accidentally fired before I managed to type anything in. Sorry for confusion.
> > > > >
> > > > > Jdb constantly reads new commands from System.in despite whether the breakpoint is hit and/or the prompt is printed.
> > > > >
> > > > > cat -n src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
> > > > >
> > > > > 786 // Process interactive commands.
> > > > > 787 MessageOutput.printPrompt();
> > > > > 788 while (true) {
> > > > > 789 String ln = in.readLine();
> > > > > 790 if (ln == null) {
> > > > > 791 /*
> > > > > 792 * Jdb is being shutdown because debuggee exited, ignore any 'null'
> > > > > 793 * returned by readLine() during shutdown. JDK-8154144.
> > > > > 794 */
> > > > > 795 if (!isShuttingDown()) {
> > > > > 796 MessageOutput.println("Input stream closed.");
> > > > > 797 }
> > > > > 798 ln = "quit";
> > > > > 799 }
> > > > > 800
> > > > > 801 if (ln.startsWith("!!")&& lastLine != null) {
> > > > > 802 ln = lastLine + ln.substring(2);
> > > > > 803 MessageOutput.printDirectln(ln);// Special case: use printDirectln()
> > > > > 804 }
> > > > > 805
> > > > > 806 StringTokenizer t = new StringTokenizer(ln);
> > > > > 807 if (t.hasMoreTokens()) {
> > > > > 808 lastLine = ln;
> > > > > 809 executeCommand(t);
> > > > > 810 } else {
> > > > > 811 MessageOutput.printPrompt();
> > > > > 812 }
> > > > > 813 }
> > > > > 814 } catch (VMDisconnectedException e) {
> > > > > 815 handler.handleDisconnectedException();
> > > > > 816 }
> > > > >
> > > > > Below is a sample debug session for the following test class that sends commands "threads" and "quit"
> > > > > 1 public class LoopTest {
> > > > > 2 public static void main(String[] args) throws Exception {
> > > > > 3 Thread thread = Thread.currentThread();
> > > > > 4 while(true) {
> > > > > 5 print(thread);
> > > > > 6 Thread.sleep(5000);
> > > > > 7 }
> > > > > 8 }
> > > > > 9
> > > > > 10 public static void print(Object obj) {
> > > > > 11 //System.out.println(obj);
> > > > > 12 }
> > > > > 13 }
> > > > >
> > > > > datitov-mac:work datitov$ ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest
> > > > > Initializing jdb ...
> > > > > > stop go at LoopTest:6
> > > > > Deferring breakpoint LoopTest:6.
> > > > > It will be set after the class is loaded.
> > > > > > run
> > > > > run LoopTest
> > > > > Set uncaught java.lang.Throwable
> > > > > Set deferred uncaught java.lang.Throwable
> > > > > >
> > > > > VM Started: Set deferred breakpoint LoopTest:6
> > > > >
> > > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > > 6 Thread.sleep(5000);
> > > > >
> > > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > > 6 Thread.sleep(5000);
> > > > > 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 sleeping
> > > > > Group InnocuousThreadGroup:
> > > > > (jdk.internal.misc.InnocuousThread)0x197 Common-Cleaner cond. waiting
> > > > > >
> > > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > > 6 Thread.sleep(5000);
> > > > >
> > > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > > 6 Thread.sleep(5000);
> > > > > quit
> > > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > > 6 Thread.sleep(5000);
> > > > >
> > > > > datitov-mac:work datitov$
> > > > >
> > > > > I think we could print a simple prompt in this case as Alex suggested.
> > > > >
> > > > > Best regards,
> > > > > Daniil
> > > > >
> > > > > On 10/17/18, 3:52 PM, "Chris Plummer"<***@oracle.com> wrote:
> > > > >
> > > > > What is the jdb state for a breakpoint with SUSPEND_NONE? Can you
> > > > > actually type in commands even though no threads are suspended?
> > > > >
> > > > > Chris
> > > > >
> > > > > On 10/17/18 3:31 PM, Alex Menkov wrote:
> > > > > > Hi Daniil, Chris,
> > > > > >
> > > > > > As far as I understand, the fix does not completely fixes all
> > > > > > "non-atomic" output issues (at least TTY.executeCommand still prints
> > > > > > prompt separately), so I agree that handle it as separate issue would
> > > > > > be better.
> > > > > > Unfortunately I don't know Gary's ideas for the issue.
> > > > > >
> > > > > > About the fix for print prompt:
> > > > > > 1) TTY.java:
> > > > > > + // Print current location if suspend policy is SUSPEND_NONE
> > > > > > I suppose you mean "Print breakpoint location"
> > > > > >
> > > > > > 2) Does it make sense to use printCurrentLocation for
> > > > > > SUSPEND_EVENT_THREAD?
> > > > > > Is it expected to print something different from printBreakpointLocation?
> > > > > >
> > > > > > 3) I don't quite understand why we don't print simple prompt for
> > > > > > SUSPEND_NONE. IIUC jdb can accept new command in both
> > > > > > SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb
> > > > > > waits for next command, right?)
> > > > > >
> > > > > > 4) JdbStopThreadTest.java
> > > > > > New line line in Java regexp is "\\R"
> > > > > >
> > > > > > --alex
> > > > > >
> > > > > > On 10/17/2018 10:47, Chris Plummer wrote:
> > > > > >> Hi Alex,
> > > > > >>
> > > > > >> I think the tty buffering should be a separate bug fix, and I'd also
> > > > > >> like input from Gary on it since he had tried something similar at
> > > > > >> one point. It should probably also include a multithread test to
> > > > > >> prove the fix is working (after first getting the test to fail
> > > > > >> without the changes).
> > > > > >>
> > > > > >> thanks,
> > > > > >>
> > > > > >> Chris
> > > > > >>
> > > > > >> On 10/16/18 8:59 PM, Daniil Titov wrote:
> > > > > >>> Hi Alex, Chris and JC,
> > > > > >>>
> > > > > >>> Please review an updated version of the patch that addresses these
> > > > > >>> issues.
> > > > > >>>
> > > > > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
> > > > > >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > > >>>
> > > > > >>> Thanks!
> > > > > >>> --Daniil
> > > > > >>>
> > > > > >>>
> > > > > >>> On 10/12/18, 9:52 AM, "Alex Menkov"<***@oracle.com> wrote:
> > > > > >>>
> > > > > >>> Hi Daniil,
> > > > > >>> 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL
> > > > > >>> 2) wrong indent in JdbStopThreadTest.java:
> > > > > >>> 36 import lib.jdb.JdbCommand;
> > > > > >>> 37 import lib.jdb.JdbTest;
> > > > > >>> 3) I think it would be better to make waitForSimplePrompt
> > > > > >>> property of
> > > > > >>> JdbCommand (like JdbCommand.allowExit)
> > > > > >>> jdb.command(JdbCommand.run().replyIsSimplePrompt());
> > > > > >>> looks much clearer than
> > > > > >>> jdb.command(JdbCommand.run(), true);
> > > > > >>> 4) (TTY.java)
> > > > > >>> MessageOutput.lnprint("Breakpoint hit:");
> > > > > >>> + // Print current location and prompt if suspend policy is
> > > > > >>> SUSPEND_EVENT_THREAD.
> > > > > >>> + // In case of SUSPEND_ALL policy this is handled by
> > > > > >>> vmInterrupted()
> > > > > >>> method.
> > > > > >>> + if (be.request().suspendPolicy() ==
> > > > > >>> EventRequest.SUSPEND_EVENT_THREAD) {
> > > > > >>> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
> > > > > >>> + MessageOutput.printPrompt();
> > > > > >>> + }
> > > > > >>> We have 3 separate outputs.
> > > > > >>> If we have several concurrent threads, we can easy get mess of
> > > > > >>> outputs
> > > > > >>> from different threads.
> > > > > >>> I think it would be better to print everything in a single chunk.
> > > > > >>> I suppose TTY has other places with similar "non-atomic"
> > > > > >>> output, so
> > > > > >>> maybe revising TTY output should be handled by separate issue.
> > > > > >>> --alex
> > > > > >>> On 10/11/2018 22:00, Chris Plummer wrote:
> > > > > >>> > Hi Daniil,
> > > > > >>> >
> > > > > >>> > Can you send output from an example jdb session?
> > > > > >>> >
> > > > > >>> > Do you think maybe we should also call printCurrentLocation()
> > > > > >>> when the
> > > > > >>> > suspend policy is NONE?
> > > > > >>> >
> > > > > >>> > There's a typo in the following line. The space is on the
> > > > > >>> wrong side of
> > > > > >>> > the comma.
> > > > > >>> >
> > > > > >>> > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
> > > > > >>> ,bpLine));
> > > > > >>> >
> > > > > >>> > thanks,
> > > > > >>> >
> > > > > >>> > Chris
> > > > > >>> >
> > > > > >>> > On 10/11/18 8:02 PM, Daniil Titov wrote:
> > > > > >>> >>
> > > > > >>> >> Thank you, JC!
> > > > > >>> >>
> > > > > >>> >> Please review an updated version of the patch that fixes
> > > > > >>> newly added
> > > > > >>> >> test for Windows platform (now it uses system dependent line
> > > > > >>> >> separator string).
> > > > > >>> >>
> > > > > >>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
> > > > > >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
> > > > > >>> >>
> > > > > >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > > >>> >>
> > > > > >>> >> Best regards,
> > > > > >>> >>
> > > > > >>> >> --Daniil
> > > > > >>> >>
> > > > > >>> >> *From: *JC Beyler<***@google.com>
> > > > > >>> >> *Date: *Thursday, October 11, 2018 at 7:17 PM
> > > > > >>> >> *To: *<***@oracle.com>
> > > > > >>> >> *Cc: *<serviceability-***@openjdk.java.net>
> > > > > >>> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when
> > > > > >>> breakpoint
> > > > > >>> >> is hit and suspend policy is STOP_EVENT_THREAD
> > > > > >>> >>
> > > > > >>> >> Hi Daniil,
> > > > > >>> >>
> > > > > >>> >> Looks good to me. I saw a really small nit:
> > > > > >>> >>
> > > > > >>> >>
> > > > > >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
> > > > > >>>
> > > > > >>> >>
> > > > > >>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
> > > > > >>>
> > > > > >>> >>
> > > > > >>> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS
> > > > > >>> ,bpLine));
> > > > > >>> >>
> > > > > >>> >> There is a space after the '('.
> > > > > >>> >>
> > > > > >>> >> No need to send a new webrev for that evidently :),
> > > > > >>> >>
> > > > > >>> >> Jc
> > > > > >>> >>
> > > > > >>> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
> > > > > >>> >> <***@oracle.com
> > > > > >>> <mailto:***@oracle.com>> wrote:
> > > > > >>> >>
> > > > > >>> >> Please review the change that fixes the issue with
> > > > > >>> missing prompt
> > > > > >>> >> in jdb when a breakpoint is hit and the suspend policy
> > > > > >>> is set to
> > > > > >>> >> stop the thread only.
> > > > > >>> >>
> > > > > >>> >> Webrev:
> > > > > >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
> > > > > >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
> > > > > >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > > >>> >>
> > > > > >>> >> Thanks!
> > > > > >>> >> --Daniil
> > > > > >>> >>
> > > > > >>> >>
> > > > > >>> >>
> > > > > >>> >> --
> > > > > >>> >>
> > > > > >>> >> Thanks,
> > > > > >>> >>
> > > > > >>> >> Jc
> > > > > >>> >>
> > > > > >>> >
> > > > > >>>
> > > > > >>>
> > > > > >>
> > > > > >>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
Chris Plummer
2018-10-22 18:18:31 UTC
Permalink
Hi Daniil,

Looks good.

thanks,

Chris

On 10/19/18 4:01 PM, Daniil Titov wrote:
> Hi Chris,
>
> Please review an updated version of the fix that makes the tests to use a custom pattern while waiting for the command to complete.
>
> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>
> Thanks!
> --Daniil
>
>
> On 10/19/18, 12:55 PM, "Chris Plummer" <***@oracle.com> wrote:
>
> On 10/19/18 9:47 AM, Daniil Titov wrote:
> > Hi Gary and Chris,
> >
> > I am resending the previous email since the table in that email got corrupted.
> >
> > Below is what output jdb prints when a breakpoint is hit depending on what suspended policy is used:
> >
> > The current behavior.
> > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed
> > SUSPEND_EVENT_THREAD: Prompt is not printed, location is not printed
> > SUSPEND_NONE: Prompt is not printed, location is not printed
> >
> > The fix changes this behavior as the following:
> >
> > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed
> > SUSPEND_EVENT_THREAD: Prompt is printed ( "> "), location is printed
> > SUSPEND_NONE: Prompt is printed ( "> "), location is printed
> I'm still in favor of this fix.
> >
> >
> > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"?
> >
> > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here...
> Maybe we need a version of command() that takes a pattern to look for
> other than the prompt.
>
> Chris
> >
> >
> > Thanks!
> > --Daniil
> >
> > On 10/19/18, 9:27 AM, "Daniil Titov" <***@oracle.com> wrote:
> >
> > Hi Gary and Chris,
> >
> > Below is the table that shows what jdb output is printed when a breakpoint is hit depending on what suspended policy is used:
> >
> > SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED
> > --------------------------------------- |---------------------------|--------------------------
> > SUSPEND_ALL. | yes, e.g. "main[1]" | yes
> > --------------------------------------- |-------------------------- |--------------------------
> > SUSPEND_EVENT_THREAD | no | no
> > ----------------------------------------|------------------------ --|--------------------------
> > SUSPEND_ALL. | no | no
> >
> >
> > The fix changes this behavior as the following:
> >
> > SUSPEND POLICY | PROMPT PRINTED. | LOCATION PRINTED
> > --------------------------------------- |----------------------------|--------------------------
> > SUSPEND_ALL. | yes , e.g. "main[1]" | yes
> > --------------------------------------- |----------------------------|--------------------------
> > SUSPEND_EVENT_THREAD | yes , ">" | yes
> > ----------------------------------------|--------------------------- |--------------------------
> > SUSPEND_ALL. | yes, ">". | yes
> >
> > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"?
> >
> > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here...
> >
> >
> > Thanks!
> >
> > Best regards,
> > Daniil
> >
> >
> >
> > On 10/19/18, 12:54 AM, "***@oracle.com" <***@oracle.com> wrote:
> >
> > It's not clear to me if the omitted location information for the non
> > stopping
> > cases was intentional or not. It may be sufficient to know that the
> > event fired
> > without the extra information.
> >
> > I don't think a settable prompt is required either. There are plenty of
> > jdb commands that
> > could be used with the wait for message in tests that need to
> > synchronize at a specific
> > point in the test sequence.
> >
> > I don't think we see wait for simple prompt in any of the tests, because it
> > is not reliable enough.
> >
> > On 10/18/18 11:53 AM, Daniil Titov wrote:
> > > Hi Gary,
> > >
> > > Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach?
> > >
> > > Thanks!
> > >
> > > Best regards,
> > > Daniil
> > >
> > >
> > >
> > > On 10/18/18, 4:09 AM, "Gary Adams" <***@oracle.com> wrote:
> > >
> > > I'm not certain that we should be printing locations or prompts for
> > > events when the vm has not been suspended. This looks OK for the
> > > simple test case we are working on here, but in real life there may
> > > be a lot more output produced.
> > >
> > > The user has to select a specific thread before additional commands
> > > can be performed in the correct context. e.g. threads, thread n, where, ...
> > > So the information is available to the user. It doesn't have to be
> > > produced at the time the event is processed.
> > >
> > > I'm uncomfortable putting too much trust in waiting for the simple prompt,
> > > because there is too great a chance of false positives on such a small
> > > marker.
> > >
> > >
> > > On 10/17/18, 8:50 PM, Daniil Titov wrote:
> > > > Hi Chris, Alex and JC,
> > > >
> > > > I created a separate issue to deal with "non-atomic" jdb output at https://bugs.openjdk.java.net/browse/JDK-8212626 .
> > > >
> > > > Please review an updated fix that includes the changes Alex suggested.
> > > >
> > > > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.04
> > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > >
> > > > Thanks!
> > > > --Daniil
> > > >
> > > >
> > > > On 10/17/18, 5:06 PM, "Daniil Titov"<***@oracle.com> wrote:
> > > >
> > > > Hi Chris,
> > > >
> > > > The previous email was accidentally fired before I managed to type anything in. Sorry for confusion.
> > > >
> > > > Jdb constantly reads new commands from System.in despite whether the breakpoint is hit and/or the prompt is printed.
> > > >
> > > > cat -n src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
> > > >
> > > > 786 // Process interactive commands.
> > > > 787 MessageOutput.printPrompt();
> > > > 788 while (true) {
> > > > 789 String ln = in.readLine();
> > > > 790 if (ln == null) {
> > > > 791 /*
> > > > 792 * Jdb is being shutdown because debuggee exited, ignore any 'null'
> > > > 793 * returned by readLine() during shutdown. JDK-8154144.
> > > > 794 */
> > > > 795 if (!isShuttingDown()) {
> > > > 796 MessageOutput.println("Input stream closed.");
> > > > 797 }
> > > > 798 ln = "quit";
> > > > 799 }
> > > > 800
> > > > 801 if (ln.startsWith("!!")&& lastLine != null) {
> > > > 802 ln = lastLine + ln.substring(2);
> > > > 803 MessageOutput.printDirectln(ln);// Special case: use printDirectln()
> > > > 804 }
> > > > 805
> > > > 806 StringTokenizer t = new StringTokenizer(ln);
> > > > 807 if (t.hasMoreTokens()) {
> > > > 808 lastLine = ln;
> > > > 809 executeCommand(t);
> > > > 810 } else {
> > > > 811 MessageOutput.printPrompt();
> > > > 812 }
> > > > 813 }
> > > > 814 } catch (VMDisconnectedException e) {
> > > > 815 handler.handleDisconnectedException();
> > > > 816 }
> > > >
> > > > Below is a sample debug session for the following test class that sends commands "threads" and "quit"
> > > > 1 public class LoopTest {
> > > > 2 public static void main(String[] args) throws Exception {
> > > > 3 Thread thread = Thread.currentThread();
> > > > 4 while(true) {
> > > > 5 print(thread);
> > > > 6 Thread.sleep(5000);
> > > > 7 }
> > > > 8 }
> > > > 9
> > > > 10 public static void print(Object obj) {
> > > > 11 //System.out.println(obj);
> > > > 12 }
> > > > 13 }
> > > >
> > > > datitov-mac:work datitov$ ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest
> > > > Initializing jdb ...
> > > > > stop go at LoopTest:6
> > > > Deferring breakpoint LoopTest:6.
> > > > It will be set after the class is loaded.
> > > > > run
> > > > run LoopTest
> > > > Set uncaught java.lang.Throwable
> > > > Set deferred uncaught java.lang.Throwable
> > > > >
> > > > VM Started: Set deferred breakpoint LoopTest:6
> > > >
> > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > 6 Thread.sleep(5000);
> > > >
> > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > 6 Thread.sleep(5000);
> > > > 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 sleeping
> > > > Group InnocuousThreadGroup:
> > > > (jdk.internal.misc.InnocuousThread)0x197 Common-Cleaner cond. waiting
> > > > >
> > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > 6 Thread.sleep(5000);
> > > >
> > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > 6 Thread.sleep(5000);
> > > > quit
> > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > 6 Thread.sleep(5000);
> > > >
> > > > datitov-mac:work datitov$
> > > >
> > > > I think we could print a simple prompt in this case as Alex suggested.
> > > >
> > > > Best regards,
> > > > Daniil
> > > >
> > > > On 10/17/18, 3:52 PM, "Chris Plummer"<***@oracle.com> wrote:
> > > >
> > > > What is the jdb state for a breakpoint with SUSPEND_NONE? Can you
> > > > actually type in commands even though no threads are suspended?
> > > >
> > > > Chris
> > > >
> > > > On 10/17/18 3:31 PM, Alex Menkov wrote:
> > > > > Hi Daniil, Chris,
> > > > >
> > > > > As far as I understand, the fix does not completely fixes all
> > > > > "non-atomic" output issues (at least TTY.executeCommand still prints
> > > > > prompt separately), so I agree that handle it as separate issue would
> > > > > be better.
> > > > > Unfortunately I don't know Gary's ideas for the issue.
> > > > >
> > > > > About the fix for print prompt:
> > > > > 1) TTY.java:
> > > > > + // Print current location if suspend policy is SUSPEND_NONE
> > > > > I suppose you mean "Print breakpoint location"
> > > > >
> > > > > 2) Does it make sense to use printCurrentLocation for
> > > > > SUSPEND_EVENT_THREAD?
> > > > > Is it expected to print something different from printBreakpointLocation?
> > > > >
> > > > > 3) I don't quite understand why we don't print simple prompt for
> > > > > SUSPEND_NONE. IIUC jdb can accept new command in both
> > > > > SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb
> > > > > waits for next command, right?)
> > > > >
> > > > > 4) JdbStopThreadTest.java
> > > > > New line line in Java regexp is "\\R"
> > > > >
> > > > > --alex
> > > > >
> > > > > On 10/17/2018 10:47, Chris Plummer wrote:
> > > > >> Hi Alex,
> > > > >>
> > > > >> I think the tty buffering should be a separate bug fix, and I'd also
> > > > >> like input from Gary on it since he had tried something similar at
> > > > >> one point. It should probably also include a multithread test to
> > > > >> prove the fix is working (after first getting the test to fail
> > > > >> without the changes).
> > > > >>
> > > > >> thanks,
> > > > >>
> > > > >> Chris
> > > > >>
> > > > >> On 10/16/18 8:59 PM, Daniil Titov wrote:
> > > > >>> Hi Alex, Chris and JC,
> > > > >>>
> > > > >>> Please review an updated version of the patch that addresses these
> > > > >>> issues.
> > > > >>>
> > > > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
> > > > >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > >>>
> > > > >>> Thanks!
> > > > >>> --Daniil
> > > > >>>
> > > > >>>
> > > > >>> On 10/12/18, 9:52 AM, "Alex Menkov"<***@oracle.com> wrote:
> > > > >>>
> > > > >>> Hi Daniil,
> > > > >>> 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL
> > > > >>> 2) wrong indent in JdbStopThreadTest.java:
> > > > >>> 36 import lib.jdb.JdbCommand;
> > > > >>> 37 import lib.jdb.JdbTest;
> > > > >>> 3) I think it would be better to make waitForSimplePrompt
> > > > >>> property of
> > > > >>> JdbCommand (like JdbCommand.allowExit)
> > > > >>> jdb.command(JdbCommand.run().replyIsSimplePrompt());
> > > > >>> looks much clearer than
> > > > >>> jdb.command(JdbCommand.run(), true);
> > > > >>> 4) (TTY.java)
> > > > >>> MessageOutput.lnprint("Breakpoint hit:");
> > > > >>> + // Print current location and prompt if suspend policy is
> > > > >>> SUSPEND_EVENT_THREAD.
> > > > >>> + // In case of SUSPEND_ALL policy this is handled by
> > > > >>> vmInterrupted()
> > > > >>> method.
> > > > >>> + if (be.request().suspendPolicy() ==
> > > > >>> EventRequest.SUSPEND_EVENT_THREAD) {
> > > > >>> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
> > > > >>> + MessageOutput.printPrompt();
> > > > >>> + }
> > > > >>> We have 3 separate outputs.
> > > > >>> If we have several concurrent threads, we can easy get mess of
> > > > >>> outputs
> > > > >>> from different threads.
> > > > >>> I think it would be better to print everything in a single chunk.
> > > > >>> I suppose TTY has other places with similar "non-atomic"
> > > > >>> output, so
> > > > >>> maybe revising TTY output should be handled by separate issue.
> > > > >>> --alex
> > > > >>> On 10/11/2018 22:00, Chris Plummer wrote:
> > > > >>> > Hi Daniil,
> > > > >>> >
> > > > >>> > Can you send output from an example jdb session?
> > > > >>> >
> > > > >>> > Do you think maybe we should also call printCurrentLocation()
> > > > >>> when the
> > > > >>> > suspend policy is NONE?
> > > > >>> >
> > > > >>> > There's a typo in the following line. The space is on the
> > > > >>> wrong side of
> > > > >>> > the comma.
> > > > >>> >
> > > > >>> > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
> > > > >>> ,bpLine));
> > > > >>> >
> > > > >>> > thanks,
> > > > >>> >
> > > > >>> > Chris
> > > > >>> >
> > > > >>> > On 10/11/18 8:02 PM, Daniil Titov wrote:
> > > > >>> >>
> > > > >>> >> Thank you, JC!
> > > > >>> >>
> > > > >>> >> Please review an updated version of the patch that fixes
> > > > >>> newly added
> > > > >>> >> test for Windows platform (now it uses system dependent line
> > > > >>> >> separator string).
> > > > >>> >>
> > > > >>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
> > > > >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
> > > > >>> >>
> > > > >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > >>> >>
> > > > >>> >> Best regards,
> > > > >>> >>
> > > > >>> >> --Daniil
> > > > >>> >>
> > > > >>> >> *From: *JC Beyler<***@google.com>
> > > > >>> >> *Date: *Thursday, October 11, 2018 at 7:17 PM
> > > > >>> >> *To: *<***@oracle.com>
> > > > >>> >> *Cc: *<serviceability-***@openjdk.java.net>
> > > > >>> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when
> > > > >>> breakpoint
> > > > >>> >> is hit and suspend policy is STOP_EVENT_THREAD
> > > > >>> >>
> > > > >>> >> Hi Daniil,
> > > > >>> >>
> > > > >>> >> Looks good to me. I saw a really small nit:
> > > > >>> >>
> > > > >>> >>
> > > > >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
> > > > >>>
> > > > >>> >>
> > > > >>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
> > > > >>>
> > > > >>> >>
> > > > >>> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS
> > > > >>> ,bpLine));
> > > > >>> >>
> > > > >>> >> There is a space after the '('.
> > > > >>> >>
> > > > >>> >> No need to send a new webrev for that evidently :),
> > > > >>> >>
> > > > >>> >> Jc
> > > > >>> >>
> > > > >>> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
> > > > >>> >> <***@oracle.com
> > > > >>> <mailto:***@oracle.com>> wrote:
> > > > >>> >>
> > > > >>> >> Please review the change that fixes the issue with
> > > > >>> missing prompt
> > > > >>> >> in jdb when a breakpoint is hit and the suspend policy
> > > > >>> is set to
> > > > >>> >> stop the thread only.
> > > > >>> >>
> > > > >>> >> Webrev:
> > > > >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
> > > > >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
> > > > >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > >>> >>
> > > > >>> >> Thanks!
> > > > >>> >> --Daniil
> > > > >>> >>
> > > > >>> >>
> > > > >>> >>
> > > > >>> >> --
> > > > >>> >>
> > > > >>> >> Thanks,
> > > > >>> >>
> > > > >>> >> Jc
> > > > >>> >>
> > > > >>> >
> > > > >>>
> > > > >>>
> > > > >>
> > > > >>
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>
Daniil Titov
2018-10-23 00:26:17 UTC
Permalink
Thank you, Chris for reviewing this change!

Alex, JC, Garry could you please say are you OK with this version of the webrev?

Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/
Issue: https://bugs.openjdk.java.net/browse/JDK-8211736

Best regards,
Daniil

On 10/22/18, 11:18 AM, "Chris Plummer" <***@oracle.com> wrote:

Hi Daniil,

Looks good.

thanks,

Chris

On 10/19/18 4:01 PM, Daniil Titov wrote:
> Hi Chris,
>
> Please review an updated version of the fix that makes the tests to use a custom pattern while waiting for the command to complete.
>
> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>
> Thanks!
> --Daniil
>
>
> On 10/19/18, 12:55 PM, "Chris Plummer" <***@oracle.com> wrote:
>
> On 10/19/18 9:47 AM, Daniil Titov wrote:
> > Hi Gary and Chris,
> >
> > I am resending the previous email since the table in that email got corrupted.
> >
> > Below is what output jdb prints when a breakpoint is hit depending on what suspended policy is used:
> >
> > The current behavior.
> > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed
> > SUSPEND_EVENT_THREAD: Prompt is not printed, location is not printed
> > SUSPEND_NONE: Prompt is not printed, location is not printed
> >
> > The fix changes this behavior as the following:
> >
> > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed
> > SUSPEND_EVENT_THREAD: Prompt is printed ( "> "), location is printed
> > SUSPEND_NONE: Prompt is printed ( "> "), location is printed
> I'm still in favor of this fix.
> >
> >
> > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"?
> >
> > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here...
> Maybe we need a version of command() that takes a pattern to look for
> other than the prompt.
>
> Chris
> >
> >
> > Thanks!
> > --Daniil
> >
> > On 10/19/18, 9:27 AM, "Daniil Titov" <***@oracle.com> wrote:
> >
> > Hi Gary and Chris,
> >
> > Below is the table that shows what jdb output is printed when a breakpoint is hit depending on what suspended policy is used:
> >
> > SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED
> > --------------------------------------- |---------------------------|--------------------------
> > SUSPEND_ALL. | yes, e.g. "main[1]" | yes
> > --------------------------------------- |-------------------------- |--------------------------
> > SUSPEND_EVENT_THREAD | no | no
> > ----------------------------------------|------------------------ --|--------------------------
> > SUSPEND_ALL. | no | no
> >
> >
> > The fix changes this behavior as the following:
> >
> > SUSPEND POLICY | PROMPT PRINTED. | LOCATION PRINTED
> > --------------------------------------- |----------------------------|--------------------------
> > SUSPEND_ALL. | yes , e.g. "main[1]" | yes
> > --------------------------------------- |----------------------------|--------------------------
> > SUSPEND_EVENT_THREAD | yes , ">" | yes
> > ----------------------------------------|--------------------------- |--------------------------
> > SUSPEND_ALL. | yes, ">". | yes
> >
> > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"?
> >
> > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here...
> >
> >
> > Thanks!
> >
> > Best regards,
> > Daniil
> >
> >
> >
> > On 10/19/18, 12:54 AM, "***@oracle.com" <***@oracle.com> wrote:
> >
> > It's not clear to me if the omitted location information for the non
> > stopping
> > cases was intentional or not. It may be sufficient to know that the
> > event fired
> > without the extra information.
> >
> > I don't think a settable prompt is required either. There are plenty of
> > jdb commands that
> > could be used with the wait for message in tests that need to
> > synchronize at a specific
> > point in the test sequence.
> >
> > I don't think we see wait for simple prompt in any of the tests, because it
> > is not reliable enough.
> >
> > On 10/18/18 11:53 AM, Daniil Titov wrote:
> > > Hi Gary,
> > >
> > > Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach?
> > >
> > > Thanks!
> > >
> > > Best regards,
> > > Daniil
> > >
> > >
> > >
> > > On 10/18/18, 4:09 AM, "Gary Adams" <***@oracle.com> wrote:
> > >
> > > I'm not certain that we should be printing locations or prompts for
> > > events when the vm has not been suspended. This looks OK for the
> > > simple test case we are working on here, but in real life there may
> > > be a lot more output produced.
> > >
> > > The user has to select a specific thread before additional commands
> > > can be performed in the correct context. e.g. threads, thread n, where, ...
> > > So the information is available to the user. It doesn't have to be
> > > produced at the time the event is processed.
> > >
> > > I'm uncomfortable putting too much trust in waiting for the simple prompt,
> > > because there is too great a chance of false positives on such a small
> > > marker.
> > >
> > >
> > > On 10/17/18, 8:50 PM, Daniil Titov wrote:
> > > > Hi Chris, Alex and JC,
> > > >
> > > > I created a separate issue to deal with "non-atomic" jdb output at https://bugs.openjdk.java.net/browse/JDK-8212626 .
> > > >
> > > > Please review an updated fix that includes the changes Alex suggested.
> > > >
> > > > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.04
> > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > >
> > > > Thanks!
> > > > --Daniil
> > > >
> > > >
> > > > On 10/17/18, 5:06 PM, "Daniil Titov"<***@oracle.com> wrote:
> > > >
> > > > Hi Chris,
> > > >
> > > > The previous email was accidentally fired before I managed to type anything in. Sorry for confusion.
> > > >
> > > > Jdb constantly reads new commands from System.in despite whether the breakpoint is hit and/or the prompt is printed.
> > > >
> > > > cat -n src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
> > > >
> > > > 786 // Process interactive commands.
> > > > 787 MessageOutput.printPrompt();
> > > > 788 while (true) {
> > > > 789 String ln = in.readLine();
> > > > 790 if (ln == null) {
> > > > 791 /*
> > > > 792 * Jdb is being shutdown because debuggee exited, ignore any 'null'
> > > > 793 * returned by readLine() during shutdown. JDK-8154144.
> > > > 794 */
> > > > 795 if (!isShuttingDown()) {
> > > > 796 MessageOutput.println("Input stream closed.");
> > > > 797 }
> > > > 798 ln = "quit";
> > > > 799 }
> > > > 800
> > > > 801 if (ln.startsWith("!!")&& lastLine != null) {
> > > > 802 ln = lastLine + ln.substring(2);
> > > > 803 MessageOutput.printDirectln(ln);// Special case: use printDirectln()
> > > > 804 }
> > > > 805
> > > > 806 StringTokenizer t = new StringTokenizer(ln);
> > > > 807 if (t.hasMoreTokens()) {
> > > > 808 lastLine = ln;
> > > > 809 executeCommand(t);
> > > > 810 } else {
> > > > 811 MessageOutput.printPrompt();
> > > > 812 }
> > > > 813 }
> > > > 814 } catch (VMDisconnectedException e) {
> > > > 815 handler.handleDisconnectedException();
> > > > 816 }
> > > >
> > > > Below is a sample debug session for the following test class that sends commands "threads" and "quit"
> > > > 1 public class LoopTest {
> > > > 2 public static void main(String[] args) throws Exception {
> > > > 3 Thread thread = Thread.currentThread();
> > > > 4 while(true) {
> > > > 5 print(thread);
> > > > 6 Thread.sleep(5000);
> > > > 7 }
> > > > 8 }
> > > > 9
> > > > 10 public static void print(Object obj) {
> > > > 11 //System.out.println(obj);
> > > > 12 }
> > > > 13 }
> > > >
> > > > datitov-mac:work datitov$ ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest
> > > > Initializing jdb ...
> > > > > stop go at LoopTest:6
> > > > Deferring breakpoint LoopTest:6.
> > > > It will be set after the class is loaded.
> > > > > run
> > > > run LoopTest
> > > > Set uncaught java.lang.Throwable
> > > > Set deferred uncaught java.lang.Throwable
> > > > >
> > > > VM Started: Set deferred breakpoint LoopTest:6
> > > >
> > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > 6 Thread.sleep(5000);
> > > >
> > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > 6 Thread.sleep(5000);
> > > > 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 sleeping
> > > > Group InnocuousThreadGroup:
> > > > (jdk.internal.misc.InnocuousThread)0x197 Common-Cleaner cond. waiting
> > > > >
> > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > 6 Thread.sleep(5000);
> > > >
> > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > 6 Thread.sleep(5000);
> > > > quit
> > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > 6 Thread.sleep(5000);
> > > >
> > > > datitov-mac:work datitov$
> > > >
> > > > I think we could print a simple prompt in this case as Alex suggested.
> > > >
> > > > Best regards,
> > > > Daniil
> > > >
> > > > On 10/17/18, 3:52 PM, "Chris Plummer"<***@oracle.com> wrote:
> > > >
> > > > What is the jdb state for a breakpoint with SUSPEND_NONE? Can you
> > > > actually type in commands even though no threads are suspended?
> > > >
> > > > Chris
> > > >
> > > > On 10/17/18 3:31 PM, Alex Menkov wrote:
> > > > > Hi Daniil, Chris,
> > > > >
> > > > > As far as I understand, the fix does not completely fixes all
> > > > > "non-atomic" output issues (at least TTY.executeCommand still prints
> > > > > prompt separately), so I agree that handle it as separate issue would
> > > > > be better.
> > > > > Unfortunately I don't know Gary's ideas for the issue.
> > > > >
> > > > > About the fix for print prompt:
> > > > > 1) TTY.java:
> > > > > + // Print current location if suspend policy is SUSPEND_NONE
> > > > > I suppose you mean "Print breakpoint location"
> > > > >
> > > > > 2) Does it make sense to use printCurrentLocation for
> > > > > SUSPEND_EVENT_THREAD?
> > > > > Is it expected to print something different from printBreakpointLocation?
> > > > >
> > > > > 3) I don't quite understand why we don't print simple prompt for
> > > > > SUSPEND_NONE. IIUC jdb can accept new command in both
> > > > > SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb
> > > > > waits for next command, right?)
> > > > >
> > > > > 4) JdbStopThreadTest.java
> > > > > New line line in Java regexp is "\\R"
> > > > >
> > > > > --alex
> > > > >
> > > > > On 10/17/2018 10:47, Chris Plummer wrote:
> > > > >> Hi Alex,
> > > > >>
> > > > >> I think the tty buffering should be a separate bug fix, and I'd also
> > > > >> like input from Gary on it since he had tried something similar at
> > > > >> one point. It should probably also include a multithread test to
> > > > >> prove the fix is working (after first getting the test to fail
> > > > >> without the changes).
> > > > >>
> > > > >> thanks,
> > > > >>
> > > > >> Chris
> > > > >>
> > > > >> On 10/16/18 8:59 PM, Daniil Titov wrote:
> > > > >>> Hi Alex, Chris and JC,
> > > > >>>
> > > > >>> Please review an updated version of the patch that addresses these
> > > > >>> issues.
> > > > >>>
> > > > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
> > > > >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > >>>
> > > > >>> Thanks!
> > > > >>> --Daniil
> > > > >>>
> > > > >>>
> > > > >>> On 10/12/18, 9:52 AM, "Alex Menkov"<***@oracle.com> wrote:
> > > > >>>
> > > > >>> Hi Daniil,
> > > > >>> 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL
> > > > >>> 2) wrong indent in JdbStopThreadTest.java:
> > > > >>> 36 import lib.jdb.JdbCommand;
> > > > >>> 37 import lib.jdb.JdbTest;
> > > > >>> 3) I think it would be better to make waitForSimplePrompt
> > > > >>> property of
> > > > >>> JdbCommand (like JdbCommand.allowExit)
> > > > >>> jdb.command(JdbCommand.run().replyIsSimplePrompt());
> > > > >>> looks much clearer than
> > > > >>> jdb.command(JdbCommand.run(), true);
> > > > >>> 4) (TTY.java)
> > > > >>> MessageOutput.lnprint("Breakpoint hit:");
> > > > >>> + // Print current location and prompt if suspend policy is
> > > > >>> SUSPEND_EVENT_THREAD.
> > > > >>> + // In case of SUSPEND_ALL policy this is handled by
> > > > >>> vmInterrupted()
> > > > >>> method.
> > > > >>> + if (be.request().suspendPolicy() ==
> > > > >>> EventRequest.SUSPEND_EVENT_THREAD) {
> > > > >>> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
> > > > >>> + MessageOutput.printPrompt();
> > > > >>> + }
> > > > >>> We have 3 separate outputs.
> > > > >>> If we have several concurrent threads, we can easy get mess of
> > > > >>> outputs
> > > > >>> from different threads.
> > > > >>> I think it would be better to print everything in a single chunk.
> > > > >>> I suppose TTY has other places with similar "non-atomic"
> > > > >>> output, so
> > > > >>> maybe revising TTY output should be handled by separate issue.
> > > > >>> --alex
> > > > >>> On 10/11/2018 22:00, Chris Plummer wrote:
> > > > >>> > Hi Daniil,
> > > > >>> >
> > > > >>> > Can you send output from an example jdb session?
> > > > >>> >
> > > > >>> > Do you think maybe we should also call printCurrentLocation()
> > > > >>> when the
> > > > >>> > suspend policy is NONE?
> > > > >>> >
> > > > >>> > There's a typo in the following line. The space is on the
> > > > >>> wrong side of
> > > > >>> > the comma.
> > > > >>> >
> > > > >>> > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
> > > > >>> ,bpLine));
> > > > >>> >
> > > > >>> > thanks,
> > > > >>> >
> > > > >>> > Chris
> > > > >>> >
> > > > >>> > On 10/11/18 8:02 PM, Daniil Titov wrote:
> > > > >>> >>
> > > > >>> >> Thank you, JC!
> > > > >>> >>
> > > > >>> >> Please review an updated version of the patch that fixes
> > > > >>> newly added
> > > > >>> >> test for Windows platform (now it uses system dependent line
> > > > >>> >> separator string).
> > > > >>> >>
> > > > >>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
> > > > >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
> > > > >>> >>
> > > > >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > >>> >>
> > > > >>> >> Best regards,
> > > > >>> >>
> > > > >>> >> --Daniil
> > > > >>> >>
> > > > >>> >> *From: *JC Beyler<***@google.com>
> > > > >>> >> *Date: *Thursday, October 11, 2018 at 7:17 PM
> > > > >>> >> *To: *<***@oracle.com>
> > > > >>> >> *Cc: *<serviceability-***@openjdk.java.net>
> > > > >>> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when
> > > > >>> breakpoint
> > > > >>> >> is hit and suspend policy is STOP_EVENT_THREAD
> > > > >>> >>
> > > > >>> >> Hi Daniil,
> > > > >>> >>
> > > > >>> >> Looks good to me. I saw a really small nit:
> > > > >>> >>
> > > > >>> >>
> > > > >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
> > > > >>>
> > > > >>> >>
> > > > >>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
> > > > >>>
> > > > >>> >>
> > > > >>> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS
> > > > >>> ,bpLine));
> > > > >>> >>
> > > > >>> >> There is a space after the '('.
> > > > >>> >>
> > > > >>> >> No need to send a new webrev for that evidently :),
> > > > >>> >>
> > > > >>> >> Jc
> > > > >>> >>
> > > > >>> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
> > > > >>> >> <***@oracle.com
> > > > >>> <mailto:***@oracle.com>> wrote:
> > > > >>> >>
> > > > >>> >> Please review the change that fixes the issue with
> > > > >>> missing prompt
> > > > >>> >> in jdb when a breakpoint is hit and the suspend policy
> > > > >>> is set to
> > > > >>> >> stop the thread only.
> > > > >>> >>
> > > > >>> >> Webrev:
> > > > >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
> > > > >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
> > > > >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > >>> >>
> > > > >>> >> Thanks!
> > > > >>> >> --Daniil
> > > > >>> >>
> > > > >>> >>
> > > > >>> >>
> > > > >>> >> --
> > > > >>> >>
> > > > >>> >> Thanks,
> > > > >>> >>
> > > > >>> >> Jc
> > > > >>> >>
> > > > >>> >
> > > > >>>
> > > > >>>
> > > > >>
> > > > >>
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>
Alex Menkov
2018-10-23 00:47:48 UTC
Permalink
I'm fine with it

--alex

On 10/22/2018 17:26, Daniil Titov wrote:
> Thank you, Chris for reviewing this change!
>
> Alex, JC, Garry could you please say are you OK with this version of the webrev?
>
> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>
> Best regards,
> Daniil
>
> On 10/22/18, 11:18 AM, "Chris Plummer" <***@oracle.com> wrote:
>
> Hi Daniil,
>
> Looks good.
>
> thanks,
>
> Chris
>
> On 10/19/18 4:01 PM, Daniil Titov wrote:
> > Hi Chris,
> >
> > Please review an updated version of the fix that makes the tests to use a custom pattern while waiting for the command to complete.
> >
> > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/
> > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> >
> > Thanks!
> > --Daniil
> >
> >
> > On 10/19/18, 12:55 PM, "Chris Plummer" <***@oracle.com> wrote:
> >
> > On 10/19/18 9:47 AM, Daniil Titov wrote:
> > > Hi Gary and Chris,
> > >
> > > I am resending the previous email since the table in that email got corrupted.
> > >
> > > Below is what output jdb prints when a breakpoint is hit depending on what suspended policy is used:
> > >
> > > The current behavior.
> > > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed
> > > SUSPEND_EVENT_THREAD: Prompt is not printed, location is not printed
> > > SUSPEND_NONE: Prompt is not printed, location is not printed
> > >
> > > The fix changes this behavior as the following:
> > >
> > > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed
> > > SUSPEND_EVENT_THREAD: Prompt is printed ( "> "), location is printed
> > > SUSPEND_NONE: Prompt is printed ( "> "), location is printed
> > I'm still in favor of this fix.
> > >
> > >
> > > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"?
> > >
> > > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here...
> > Maybe we need a version of command() that takes a pattern to look for
> > other than the prompt.
> >
> > Chris
> > >
> > >
> > > Thanks!
> > > --Daniil
> > >
> > > On 10/19/18, 9:27 AM, "Daniil Titov" <***@oracle.com> wrote:
> > >
> > > Hi Gary and Chris,
> > >
> > > Below is the table that shows what jdb output is printed when a breakpoint is hit depending on what suspended policy is used:
> > >
> > > SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED
> > > --------------------------------------- |---------------------------|--------------------------
> > > SUSPEND_ALL. | yes, e.g. "main[1]" | yes
> > > --------------------------------------- |-------------------------- |--------------------------
> > > SUSPEND_EVENT_THREAD | no | no
> > > ----------------------------------------|------------------------ --|--------------------------
> > > SUSPEND_ALL. | no | no
> > >
> > >
> > > The fix changes this behavior as the following:
> > >
> > > SUSPEND POLICY | PROMPT PRINTED. | LOCATION PRINTED
> > > --------------------------------------- |----------------------------|--------------------------
> > > SUSPEND_ALL. | yes , e.g. "main[1]" | yes
> > > --------------------------------------- |----------------------------|--------------------------
> > > SUSPEND_EVENT_THREAD | yes , ">" | yes
> > > ----------------------------------------|--------------------------- |--------------------------
> > > SUSPEND_ALL. | yes, ">". | yes
> > >
> > > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"?
> > >
> > > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here...
> > >
> > >
> > > Thanks!
> > >
> > > Best regards,
> > > Daniil
> > >
> > >
> > >
> > > On 10/19/18, 12:54 AM, "***@oracle.com" <***@oracle.com> wrote:
> > >
> > > It's not clear to me if the omitted location information for the non
> > > stopping
> > > cases was intentional or not. It may be sufficient to know that the
> > > event fired
> > > without the extra information.
> > >
> > > I don't think a settable prompt is required either. There are plenty of
> > > jdb commands that
> > > could be used with the wait for message in tests that need to
> > > synchronize at a specific
> > > point in the test sequence.
> > >
> > > I don't think we see wait for simple prompt in any of the tests, because it
> > > is not reliable enough.
> > >
> > > On 10/18/18 11:53 AM, Daniil Titov wrote:
> > > > Hi Gary,
> > > >
> > > > Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach?
> > > >
> > > > Thanks!
> > > >
> > > > Best regards,
> > > > Daniil
> > > >
> > > >
> > > >
> > > > On 10/18/18, 4:09 AM, "Gary Adams" <***@oracle.com> wrote:
> > > >
> > > > I'm not certain that we should be printing locations or prompts for
> > > > events when the vm has not been suspended. This looks OK for the
> > > > simple test case we are working on here, but in real life there may
> > > > be a lot more output produced.
> > > >
> > > > The user has to select a specific thread before additional commands
> > > > can be performed in the correct context. e.g. threads, thread n, where, ...
> > > > So the information is available to the user. It doesn't have to be
> > > > produced at the time the event is processed.
> > > >
> > > > I'm uncomfortable putting too much trust in waiting for the simple prompt,
> > > > because there is too great a chance of false positives on such a small
> > > > marker.
> > > >
> > > >
> > > > On 10/17/18, 8:50 PM, Daniil Titov wrote:
> > > > > Hi Chris, Alex and JC,
> > > > >
> > > > > I created a separate issue to deal with "non-atomic" jdb output at https://bugs.openjdk.java.net/browse/JDK-8212626 .
> > > > >
> > > > > Please review an updated fix that includes the changes Alex suggested.
> > > > >
> > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.04
> > > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > >
> > > > > Thanks!
> > > > > --Daniil
> > > > >
> > > > >
> > > > > On 10/17/18, 5:06 PM, "Daniil Titov"<***@oracle.com> wrote:
> > > > >
> > > > > Hi Chris,
> > > > >
> > > > > The previous email was accidentally fired before I managed to type anything in. Sorry for confusion.
> > > > >
> > > > > Jdb constantly reads new commands from System.in despite whether the breakpoint is hit and/or the prompt is printed.
> > > > >
> > > > > cat -n src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
> > > > >
> > > > > 786 // Process interactive commands.
> > > > > 787 MessageOutput.printPrompt();
> > > > > 788 while (true) {
> > > > > 789 String ln = in.readLine();
> > > > > 790 if (ln == null) {
> > > > > 791 /*
> > > > > 792 * Jdb is being shutdown because debuggee exited, ignore any 'null'
> > > > > 793 * returned by readLine() during shutdown. JDK-8154144.
> > > > > 794 */
> > > > > 795 if (!isShuttingDown()) {
> > > > > 796 MessageOutput.println("Input stream closed.");
> > > > > 797 }
> > > > > 798 ln = "quit";
> > > > > 799 }
> > > > > 800
> > > > > 801 if (ln.startsWith("!!")&& lastLine != null) {
> > > > > 802 ln = lastLine + ln.substring(2);
> > > > > 803 MessageOutput.printDirectln(ln);// Special case: use printDirectln()
> > > > > 804 }
> > > > > 805
> > > > > 806 StringTokenizer t = new StringTokenizer(ln);
> > > > > 807 if (t.hasMoreTokens()) {
> > > > > 808 lastLine = ln;
> > > > > 809 executeCommand(t);
> > > > > 810 } else {
> > > > > 811 MessageOutput.printPrompt();
> > > > > 812 }
> > > > > 813 }
> > > > > 814 } catch (VMDisconnectedException e) {
> > > > > 815 handler.handleDisconnectedException();
> > > > > 816 }
> > > > >
> > > > > Below is a sample debug session for the following test class that sends commands "threads" and "quit"
> > > > > 1 public class LoopTest {
> > > > > 2 public static void main(String[] args) throws Exception {
> > > > > 3 Thread thread = Thread.currentThread();
> > > > > 4 while(true) {
> > > > > 5 print(thread);
> > > > > 6 Thread.sleep(5000);
> > > > > 7 }
> > > > > 8 }
> > > > > 9
> > > > > 10 public static void print(Object obj) {
> > > > > 11 //System.out.println(obj);
> > > > > 12 }
> > > > > 13 }
> > > > >
> > > > > datitov-mac:work datitov$ ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest
> > > > > Initializing jdb ...
> > > > > > stop go at LoopTest:6
> > > > > Deferring breakpoint LoopTest:6.
> > > > > It will be set after the class is loaded.
> > > > > > run
> > > > > run LoopTest
> > > > > Set uncaught java.lang.Throwable
> > > > > Set deferred uncaught java.lang.Throwable
> > > > > >
> > > > > VM Started: Set deferred breakpoint LoopTest:6
> > > > >
> > > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > > 6 Thread.sleep(5000);
> > > > >
> > > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > > 6 Thread.sleep(5000);
> > > > > 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 sleeping
> > > > > Group InnocuousThreadGroup:
> > > > > (jdk.internal.misc.InnocuousThread)0x197 Common-Cleaner cond. waiting
> > > > > >
> > > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > > 6 Thread.sleep(5000);
> > > > >
> > > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > > 6 Thread.sleep(5000);
> > > > > quit
> > > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
> > > > > 6 Thread.sleep(5000);
> > > > >
> > > > > datitov-mac:work datitov$
> > > > >
> > > > > I think we could print a simple prompt in this case as Alex suggested.
> > > > >
> > > > > Best regards,
> > > > > Daniil
> > > > >
> > > > > On 10/17/18, 3:52 PM, "Chris Plummer"<***@oracle.com> wrote:
> > > > >
> > > > > What is the jdb state for a breakpoint with SUSPEND_NONE? Can you
> > > > > actually type in commands even though no threads are suspended?
> > > > >
> > > > > Chris
> > > > >
> > > > > On 10/17/18 3:31 PM, Alex Menkov wrote:
> > > > > > Hi Daniil, Chris,
> > > > > >
> > > > > > As far as I understand, the fix does not completely fixes all
> > > > > > "non-atomic" output issues (at least TTY.executeCommand still prints
> > > > > > prompt separately), so I agree that handle it as separate issue would
> > > > > > be better.
> > > > > > Unfortunately I don't know Gary's ideas for the issue.
> > > > > >
> > > > > > About the fix for print prompt:
> > > > > > 1) TTY.java:
> > > > > > + // Print current location if suspend policy is SUSPEND_NONE
> > > > > > I suppose you mean "Print breakpoint location"
> > > > > >
> > > > > > 2) Does it make sense to use printCurrentLocation for
> > > > > > SUSPEND_EVENT_THREAD?
> > > > > > Is it expected to print something different from printBreakpointLocation?
> > > > > >
> > > > > > 3) I don't quite understand why we don't print simple prompt for
> > > > > > SUSPEND_NONE. IIUC jdb can accept new command in both
> > > > > > SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb
> > > > > > waits for next command, right?)
> > > > > >
> > > > > > 4) JdbStopThreadTest.java
> > > > > > New line line in Java regexp is "\\R"
> > > > > >
> > > > > > --alex
> > > > > >
> > > > > > On 10/17/2018 10:47, Chris Plummer wrote:
> > > > > >> Hi Alex,
> > > > > >>
> > > > > >> I think the tty buffering should be a separate bug fix, and I'd also
> > > > > >> like input from Gary on it since he had tried something similar at
> > > > > >> one point. It should probably also include a multithread test to
> > > > > >> prove the fix is working (after first getting the test to fail
> > > > > >> without the changes).
> > > > > >>
> > > > > >> thanks,
> > > > > >>
> > > > > >> Chris
> > > > > >>
> > > > > >> On 10/16/18 8:59 PM, Daniil Titov wrote:
> > > > > >>> Hi Alex, Chris and JC,
> > > > > >>>
> > > > > >>> Please review an updated version of the patch that addresses these
> > > > > >>> issues.
> > > > > >>>
> > > > > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
> > > > > >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > > >>>
> > > > > >>> Thanks!
> > > > > >>> --Daniil
> > > > > >>>
> > > > > >>>
> > > > > >>> On 10/12/18, 9:52 AM, "Alex Menkov"<***@oracle.com> wrote:
> > > > > >>>
> > > > > >>> Hi Daniil,
> > > > > >>> 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL
> > > > > >>> 2) wrong indent in JdbStopThreadTest.java:
> > > > > >>> 36 import lib.jdb.JdbCommand;
> > > > > >>> 37 import lib.jdb.JdbTest;
> > > > > >>> 3) I think it would be better to make waitForSimplePrompt
> > > > > >>> property of
> > > > > >>> JdbCommand (like JdbCommand.allowExit)
> > > > > >>> jdb.command(JdbCommand.run().replyIsSimplePrompt());
> > > > > >>> looks much clearer than
> > > > > >>> jdb.command(JdbCommand.run(), true);
> > > > > >>> 4) (TTY.java)
> > > > > >>> MessageOutput.lnprint("Breakpoint hit:");
> > > > > >>> + // Print current location and prompt if suspend policy is
> > > > > >>> SUSPEND_EVENT_THREAD.
> > > > > >>> + // In case of SUSPEND_ALL policy this is handled by
> > > > > >>> vmInterrupted()
> > > > > >>> method.
> > > > > >>> + if (be.request().suspendPolicy() ==
> > > > > >>> EventRequest.SUSPEND_EVENT_THREAD) {
> > > > > >>> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
> > > > > >>> + MessageOutput.printPrompt();
> > > > > >>> + }
> > > > > >>> We have 3 separate outputs.
> > > > > >>> If we have several concurrent threads, we can easy get mess of
> > > > > >>> outputs
> > > > > >>> from different threads.
> > > > > >>> I think it would be better to print everything in a single chunk.
> > > > > >>> I suppose TTY has other places with similar "non-atomic"
> > > > > >>> output, so
> > > > > >>> maybe revising TTY output should be handled by separate issue.
> > > > > >>> --alex
> > > > > >>> On 10/11/2018 22:00, Chris Plummer wrote:
> > > > > >>> > Hi Daniil,
> > > > > >>> >
> > > > > >>> > Can you send output from an example jdb session?
> > > > > >>> >
> > > > > >>> > Do you think maybe we should also call printCurrentLocation()
> > > > > >>> when the
> > > > > >>> > suspend policy is NONE?
> > > > > >>> >
> > > > > >>> > There's a typo in the following line. The space is on the
> > > > > >>> wrong side of
> > > > > >>> > the comma.
> > > > > >>> >
> > > > > >>> > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
> > > > > >>> ,bpLine));
> > > > > >>> >
> > > > > >>> > thanks,
> > > > > >>> >
> > > > > >>> > Chris
> > > > > >>> >
> > > > > >>> > On 10/11/18 8:02 PM, Daniil Titov wrote:
> > > > > >>> >>
> > > > > >>> >> Thank you, JC!
> > > > > >>> >>
> > > > > >>> >> Please review an updated version of the patch that fixes
> > > > > >>> newly added
> > > > > >>> >> test for Windows platform (now it uses system dependent line
> > > > > >>> >> separator string).
> > > > > >>> >>
> > > > > >>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
> > > > > >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
> > > > > >>> >>
> > > > > >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > > >>> >>
> > > > > >>> >> Best regards,
> > > > > >>> >>
> > > > > >>> >> --Daniil
> > > > > >>> >>
> > > > > >>> >> *From: *JC Beyler<***@google.com>
> > > > > >>> >> *Date: *Thursday, October 11, 2018 at 7:17 PM
> > > > > >>> >> *To: *<***@oracle.com>
> > > > > >>> >> *Cc: *<serviceability-***@openjdk.java.net>
> > > > > >>> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when
> > > > > >>> breakpoint
> > > > > >>> >> is hit and suspend policy is STOP_EVENT_THREAD
> > > > > >>> >>
> > > > > >>> >> Hi Daniil,
> > > > > >>> >>
> > > > > >>> >> Looks good to me. I saw a really small nit:
> > > > > >>> >>
> > > > > >>> >>
> > > > > >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
> > > > > >>>
> > > > > >>> >>
> > > > > >>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
> > > > > >>>
> > > > > >>> >>
> > > > > >>> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS
> > > > > >>> ,bpLine));
> > > > > >>> >>
> > > > > >>> >> There is a space after the '('.
> > > > > >>> >>
> > > > > >>> >> No need to send a new webrev for that evidently :),
> > > > > >>> >>
> > > > > >>> >> Jc
> > > > > >>> >>
> > > > > >>> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
> > > > > >>> >> <***@oracle.com
> > > > > >>> <mailto:***@oracle.com>> wrote:
> > > > > >>> >>
> > > > > >>> >> Please review the change that fixes the issue with
> > > > > >>> missing prompt
> > > > > >>> >> in jdb when a breakpoint is hit and the suspend policy
> > > > > >>> is set to
> > > > > >>> >> stop the thread only.
> > > > > >>> >>
> > > > > >>> >> Webrev:
> > > > > >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
> > > > > >>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
> > > > > >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > > >>> >>
> > > > > >>> >> Thanks!
> > > > > >>> >> --Daniil
> > > > > >>> >>
> > > > > >>> >>
> > > > > >>> >>
> > > > > >>> >> --
> > > > > >>> >>
> > > > > >>> >> Thanks,
> > > > > >>> >>
> > > > > >>> >> Jc
> > > > > >>> >>
> > > > > >>> >
> > > > > >>>
> > > > > >>>
> > > > > >>
> > > > > >>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>
JC Beyler
2018-10-23 02:49:29 UTC
Permalink
LGTM as well,
Jc

On Mon, Oct 22, 2018 at 5:47 PM Alex Menkov <***@oracle.com>
wrote:

> I'm fine with it
>
> --alex
>
> On 10/22/2018 17:26, Daniil Titov wrote:
> > Thank you, Chris for reviewing this change!
> >
> > Alex, JC, Garry could you please say are you OK with this version of the
> webrev?
> >
> > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/
> > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> >
> > Best regards,
> > Daniil
> >
> > On 10/22/18, 11:18 AM, "Chris Plummer" <***@oracle.com>
> wrote:
> >
> > Hi Daniil,
> >
> > Looks good.
> >
> > thanks,
> >
> > Chris
> >
> > On 10/19/18 4:01 PM, Daniil Titov wrote:
> > > Hi Chris,
> > >
> > > Please review an updated version of the fix that makes the tests
> to use a custom pattern while waiting for the command to complete.
> > >
> > > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/
> > > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
> > >
> > > Thanks!
> > > --Daniil
> > >
> > >
> > > On 10/19/18, 12:55 PM, "Chris Plummer" <***@oracle.com>
> wrote:
> > >
> > > On 10/19/18 9:47 AM, Daniil Titov wrote:
> > > > Hi Gary and Chris,
> > > >
> > > > I am resending the previous email since the table in that
> email got corrupted.
> > > >
> > > > Below is what output jdb prints when a breakpoint is hit
> depending on what suspended policy is used:
> > > >
> > > > The current behavior.
> > > > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"),
> location is printed
> > > > SUSPEND_EVENT_THREAD: Prompt is not printed, location
> is not printed
> > > > SUSPEND_NONE: Prompt is not printed, location is not
> printed
> > > >
> > > > The fix changes this behavior as the following:
> > > >
> > > > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"),
> location is printed
> > > > SUSPEND_EVENT_THREAD: Prompt is printed ( "> "),
> location is printed
> > > > SUSPEND_NONE: Prompt is printed ( "> "), location is
> printed
> > > I'm still in favor of this fix.
> > > >
> > > >
> > > > Could you please say is it OK for you or you want that the
> location was printed only for SUSPEND_ALL case? Or probably just leave all
> behavior unchanged and close the bug as "not an issue"?
> > > >
> > > > Regarding settable prompt... As I understand Gary's
> original concern was that waiting in tests for a simple prompt " > "
> (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the
> output of the test program and the suggestion was to use more specific
> patterns for the cases when the full prompt (thread_name[frame_index]) is
> not printed ( e.g. when the current thread is not set). However, we need
> somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it
> would keep waiting for the full prompt and fail with the timeout. Probably
> I am missing something here...
> > > Maybe we need a version of command() that takes a pattern to
> look for
> > > other than the prompt.
> > >
> > > Chris
> > > >
> > > >
> > > > Thanks!
> > > > --Daniil
> > > >
> > > > On 10/19/18, 9:27 AM, "Daniil Titov" <
> ***@oracle.com> wrote:
> > > >
> > > > Hi Gary and Chris,
> > > >
> > > > Below is the table that shows what jdb output is
> printed when a breakpoint is hit depending on what suspended policy is used:
> > > >
> > > > SUSPEND POLICY | PROMPT
> PRINTED | LOCATION PRINTED
> > > > ---------------------------------------
> |---------------------------|--------------------------
> > > > SUSPEND_ALL. | yes, e.g.
> "main[1]" | yes
> > > > ---------------------------------------
> |-------------------------- |--------------------------
> > > > SUSPEND_EVENT_THREAD | no |
> no
> > > >
> ----------------------------------------|------------------------
> --|--------------------------
> > > > SUSPEND_ALL. | no
> | no
> > > >
> > > >
> > > > The fix changes this behavior as the following:
> > > >
> > > > SUSPEND POLICY | PROMPT
> PRINTED. | LOCATION PRINTED
> > > > ---------------------------------------
> |----------------------------|--------------------------
> > > > SUSPEND_ALL. | yes , e.g.
> "main[1]" | yes
> > > > ---------------------------------------
> |----------------------------|--------------------------
> > > > SUSPEND_EVENT_THREAD | yes , ">"
> | yes
> > > >
> ----------------------------------------|---------------------------
> |--------------------------
> > > > SUSPEND_ALL. | yes, ">".
> | yes
> > > >
> > > > Could you please say is it OK for you or you want
> that the location was printed only for SUSPEND_ALL case? Or probably just
> leave all behavior unchanged and close the bug as "not an issue"?
> > > >
> > > > Regarding settable prompt... As I understand Gary's
> original concern was that waiting in tests for a simple prompt " > "
> (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the
> output of the test program and the suggestion was to use more specific
> patterns for the cases when the full prompt (thread_name[frame_index]) is
> not printed ( e.g. when the current thread is not set). However, we need
> somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it
> would keep waiting for the full prompt and fail with the timeout. Probably
> I am missing something here...
> > > >
> > > >
> > > > Thanks!
> > > >
> > > > Best regards,
> > > > Daniil
> > > >
> > > >
> > > >
> > > > On 10/19/18, 12:54 AM, "***@oracle.com" <
> ***@oracle.com> wrote:
> > > >
> > > > It's not clear to me if the omitted location
> information for the non
> > > > stopping
> > > > cases was intentional or not. It may be
> sufficient to know that the
> > > > event fired
> > > > without the extra information.
> > > >
> > > > I don't think a settable prompt is required
> either. There are plenty of
> > > > jdb commands that
> > > > could be used with the wait for message in tests
> that need to
> > > > synchronize at a specific
> > > > point in the test sequence.
> > > >
> > > > I don't think we see wait for simple prompt in
> any of the tests, because it
> > > > is not reliable enough.
> > > >
> > > > On 10/18/18 11:53 AM, Daniil Titov wrote:
> > > > > Hi Gary,
> > > > >
> > > > > Currently when a breakpoint is hit the message
> "Breakpoint hit:" is printed in the debugger output. What we do in this fix
> we just add more information about what exact breakpoint is hit. Do you
> suggest we should not print this line at all if suspend policy is
> SUSPEND_NONE? If so then it is not clear what is the use of the command
> "stop go ..." would be. Regarding waiting for the simple prompt, we could
> change JDbCommand to have a field to store a prompt pattern and use this
> pattern (if it was set) when waiting for command to complete. In tests when
> required we would set the pattern in JdbCommand to more complicated one
> matching a specific output we are expecting at this particular step. Do you
> think it would be a better approach?
> > > > >
> > > > > Thanks!
> > > > >
> > > > > Best regards,
> > > > > Daniil
> > > > >
> > > > >
> > > > >
> > > > > On 10/18/18, 4:09 AM, "Gary Adams" <
> ***@oracle.com> wrote:
> > > > >
> > > > > I'm not certain that we should be printing
> locations or prompts for
> > > > > events when the vm has not been suspended.
> This looks OK for the
> > > > > simple test case we are working on here,
> but in real life there may
> > > > > be a lot more output produced.
> > > > >
> > > > > The user has to select a specific thread
> before additional commands
> > > > > can be performed in the correct context.
> e.g. threads, thread n, where, ...
> > > > > So the information is available to the
> user. It doesn't have to be
> > > > > produced at the time the event is
> processed.
> > > > >
> > > > > I'm uncomfortable putting too much trust
> in waiting for the simple prompt,
> > > > > because there is too great a chance of
> false positives on such a small
> > > > > marker.
> > > > >
> > > > >
> > > > > On 10/17/18, 8:50 PM, Daniil Titov wrote:
> > > > > > Hi Chris, Alex and JC,
> > > > > >
> > > > > > I created a separate issue to deal with
> "non-atomic" jdb output at
> https://bugs.openjdk.java.net/browse/JDK-8212626 .
> > > > > >
> > > > > > Please review an updated fix that
> includes the changes Alex suggested.
> > > > > >
> > > > > > Webrev:
> http://cr.openjdk.java.net/~dtitov/8211736/webrev.04
> > > > > > Issue:
> https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > > >
> > > > > > Thanks!
> > > > > > --Daniil
> > > > > >
> > > > > >
> > > > > > On 10/17/18, 5:06 PM, "Daniil Titov"<
> ***@oracle.com> wrote:
> > > > > >
> > > > > > Hi Chris,
> > > > > >
> > > > > > The previous email was accidentally
> fired before I managed to type anything in. Sorry for confusion.
> > > > > >
> > > > > > Jdb constantly reads new commands
> from System.in despite whether the breakpoint is hit and/or the prompt is
> printed.
> > > > > >
> > > > > > cat -n
> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
> > > > > >
> > > > > > 786 // Process
> interactive commands.
> > > > > > 787
> MessageOutput.printPrompt();
> > > > > > 788 while (true) {
> > > > > > 789 String ln
> = in.readLine();
> > > > > > 790 if (ln ==
> null) {
> > > > > > 791 /*
> > > > > > 792 *
> Jdb is being shutdown because debuggee exited, ignore any 'null'
> > > > > > 793 *
> returned by readLine() during shutdown. JDK-8154144.
> > > > > > 794 */
> > > > > > 795 if
> (!isShuttingDown()) {
> > > > > > 796
> MessageOutput.println("Input stream closed.");
> > > > > > 797 }
> > > > > > 798 ln =
> "quit";
> > > > > > 799 }
> > > > > > 800
> > > > > > 801 if
> (ln.startsWith("!!")&& lastLine != null) {
> > > > > > 802 ln =
> lastLine + ln.substring(2);
> > > > > > 803
> MessageOutput.printDirectln(ln);// Special case: use printDirectln()
> > > > > > 804 }
> > > > > > 805
> > > > > > 806
> StringTokenizer t = new StringTokenizer(ln);
> > > > > > 807 if
> (t.hasMoreTokens()) {
> > > > > > 808
> lastLine = ln;
> > > > > > 809
> executeCommand(t);
> > > > > > 810 } else {
> > > > > > 811
> MessageOutput.printPrompt();
> > > > > > 812 }
> > > > > > 813 }
> > > > > > 814 } catch
> (VMDisconnectedException e) {
> > > > > > 815
> handler.handleDisconnectedException();
> > > > > > 816 }
> > > > > >
> > > > > > Below is a sample debug session for
> the following test class that sends commands "threads" and "quit"
> > > > > > 1 public class LoopTest {
> > > > > > 2 public static void
> main(String[] args) throws Exception {
> > > > > > 3 Thread thread =
> Thread.currentThread();
> > > > > > 4 while(true) {
> > > > > > 5 print(thread);
> > > > > > 6
> Thread.sleep(5000);
> > > > > > 7 }
> > > > > > 8 }
> > > > > > 9
> > > > > > 10 public static void
> print(Object obj) {
> > > > > > 11
> //System.out.println(obj);
> > > > > > 12 }
> > > > > > 13 }
> > > > > >
> > > > > > datitov-mac:work datitov$
> ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest
> > > > > > Initializing jdb ...
> > > > > > > stop go at LoopTest:6
> > > > > > Deferring breakpoint LoopTest:6.
> > > > > > It will be set after the class is
> loaded.
> > > > > > > run
> > > > > > run LoopTest
> > > > > > Set uncaught java.lang.Throwable
> > > > > > Set deferred uncaught
> java.lang.Throwable
> > > > > > >
> > > > > > VM Started: Set deferred breakpoint
> LoopTest:6
> > > > > >
> > > > > > Breakpoint hit: "thread=main",
> LoopTest.main(), line=6 bci=8
> > > > > > 6 Thread.sleep(5000);
> > > > > >
> > > > > > Breakpoint hit: "thread=main",
> LoopTest.main(), line=6 bci=8
> > > > > > 6 Thread.sleep(5000);
> > > > > > 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 sleeping
> > > > > > Group InnocuousThreadGroup:
> > > > > >
> (jdk.internal.misc.InnocuousThread)0x197 Common-Cleaner cond.
> waiting
> > > > > > >
> > > > > > Breakpoint hit: "thread=main",
> LoopTest.main(), line=6 bci=8
> > > > > > 6 Thread.sleep(5000);
> > > > > >
> > > > > > Breakpoint hit: "thread=main",
> LoopTest.main(), line=6 bci=8
> > > > > > 6 Thread.sleep(5000);
> > > > > > quit
> > > > > > Breakpoint hit: "thread=main",
> LoopTest.main(), line=6 bci=8
> > > > > > 6 Thread.sleep(5000);
> > > > > >
> > > > > > datitov-mac:work datitov$
> > > > > >
> > > > > > I think we could print a simple
> prompt in this case as Alex suggested.
> > > > > >
> > > > > > Best regards,
> > > > > > Daniil
> > > > > >
> > > > > > On 10/17/18, 3:52 PM, "Chris
> Plummer"<***@oracle.com> wrote:
> > > > > >
> > > > > > What is the jdb state for a
> breakpoint with SUSPEND_NONE? Can you
> > > > > > actually type in commands even
> though no threads are suspended?
> > > > > >
> > > > > > Chris
> > > > > >
> > > > > > On 10/17/18 3:31 PM, Alex
> Menkov wrote:
> > > > > > > Hi Daniil, Chris,
> > > > > > >
> > > > > > > As far as I understand, the
> fix does not completely fixes all
> > > > > > > "non-atomic" output issues
> (at least TTY.executeCommand still prints
> > > > > > > prompt separately), so I
> agree that handle it as separate issue would
> > > > > > > be better.
> > > > > > > Unfortunately I don't know
> Gary's ideas for the issue.
> > > > > > >
> > > > > > > About the fix for print
> prompt:
> > > > > > > 1) TTY.java:
> > > > > > > + // Print
> current location if suspend policy is SUSPEND_NONE
> > > > > > > I suppose you mean "Print
> breakpoint location"
> > > > > > >
> > > > > > > 2) Does it make sense to use
> printCurrentLocation for
> > > > > > > SUSPEND_EVENT_THREAD?
> > > > > > > Is it expected to print
> something different from printBreakpointLocation?
> > > > > > >
> > > > > > > 3) I don't quite understand
> why we don't print simple prompt for
> > > > > > > SUSPEND_NONE. IIUC jdb can
> accept new command in both
> > > > > > > SUSPEND_EVENT_THREAD and
> SUSPEND_NONE cases (prompt shows that jdb
> > > > > > > waits for next command,
> right?)
> > > > > > >
> > > > > > > 4) JdbStopThreadTest.java
> > > > > > > New line line in Java regexp
> is "\\R"
> > > > > > >
> > > > > > > --alex
> > > > > > >
> > > > > > > On 10/17/2018 10:47, Chris
> Plummer wrote:
> > > > > > >> Hi Alex,
> > > > > > >>
> > > > > > >> I think the tty buffering
> should be a separate bug fix, and I'd also
> > > > > > >> like input from Gary on it
> since he had tried something similar at
> > > > > > >> one point. It should
> probably also include a multithread test to
> > > > > > >> prove the fix is working
> (after first getting the test to fail
> > > > > > >> without the changes).
> > > > > > >>
> > > > > > >> thanks,
> > > > > > >>
> > > > > > >> Chris
> > > > > > >>
> > > > > > >> On 10/16/18 8:59 PM, Daniil
> Titov wrote:
> > > > > > >>> Hi Alex, Chris and JC,
> > > > > > >>>
> > > > > > >>> Please review an updated
> version of the patch that addresses these
> > > > > > >>> issues.
> > > > > > >>>
> > > > > > >>> Webrev:
> http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
> > > > > > >>> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > > > >>>
> > > > > > >>> Thanks!
> > > > > > >>> --Daniil
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> On 10/12/18, 9:52 AM,
> "Alex Menkov"<***@oracle.com> wrote:
> > > > > > >>>
> > > > > > >>> Hi Daniil,
> > > > > > >>> 1) +1 for
> printCurrentLocation when suspendPolicy != SUSPEND_ALL
> > > > > > >>> 2) wrong indent in
> JdbStopThreadTest.java:
> > > > > > >>> 36 import
> lib.jdb.JdbCommand;
> > > > > > >>> 37 import
> lib.jdb.JdbTest;
> > > > > > >>> 3) I think it would
> be better to make waitForSimplePrompt
> > > > > > >>> property of
> > > > > > >>> JdbCommand (like
> JdbCommand.allowExit)
> > > > > > >>>
> jdb.command(JdbCommand.run().replyIsSimplePrompt());
> > > > > > >>> looks much clearer
> than
> > > > > > >>>
> jdb.command(JdbCommand.run(), true);
> > > > > > >>> 4) (TTY.java)
> > > > > > >>>
> MessageOutput.lnprint("Breakpoint hit:");
> > > > > > >>> + // Print current
> location and prompt if suspend policy is
> > > > > > >>> SUSPEND_EVENT_THREAD.
> > > > > > >>> + // In case of
> SUSPEND_ALL policy this is handled by
> > > > > > >>> vmInterrupted()
> > > > > > >>> method.
> > > > > > >>> + if
> (be.request().suspendPolicy() ==
> > > > > > >>>
> EventRequest.SUSPEND_EVENT_THREAD) {
> > > > > > >>> +
> printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
> > > > > > >>> +
> MessageOutput.printPrompt();
> > > > > > >>> + }
> > > > > > >>> We have 3 separate
> outputs.
> > > > > > >>> If we have several
> concurrent threads, we can easy get mess of
> > > > > > >>> outputs
> > > > > > >>> from different
> threads.
> > > > > > >>> I think it would be
> better to print everything in a single chunk.
> > > > > > >>> I suppose TTY has
> other places with similar "non-atomic"
> > > > > > >>> output, so
> > > > > > >>> maybe revising TTY
> output should be handled by separate issue.
> > > > > > >>> --alex
> > > > > > >>> On 10/11/2018 22:00,
> Chris Plummer wrote:
> > > > > > >>> > Hi Daniil,
> > > > > > >>> >
> > > > > > >>> > Can you send
> output from an example jdb session?
> > > > > > >>> >
> > > > > > >>> > Do you think maybe
> we should also call printCurrentLocation()
> > > > > > >>> when the
> > > > > > >>> > suspend policy is
> NONE?
> > > > > > >>> >
> > > > > > >>> > There's a typo in
> the following line. The space is on the
> > > > > > >>> wrong side of
> > > > > > >>> > the comma.
> > > > > > >>> >
> > > > > > >>> > 72
> jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
> > > > > > >>> ,bpLine));
> > > > > > >>> >
> > > > > > >>> > thanks,
> > > > > > >>> >
> > > > > > >>> > Chris
> > > > > > >>> >
> > > > > > >>> > On 10/11/18 8:02
> PM, Daniil Titov wrote:
> > > > > > >>> >>
> > > > > > >>> >> Thank you, JC!
> > > > > > >>> >>
> > > > > > >>> >> Please review an
> updated version of the patch that fixes
> > > > > > >>> newly added
> > > > > > >>> >> test for Windows
> platform (now it uses system dependent line
> > > > > > >>> >> separator string).
> > > > > > >>> >>
> > > > > > >>> >> Webrev:
> http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
> > > > > > >>> >> <
> http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
> > > > > > >>> >>
> > > > > > >>> >> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > > > >>> >>
> > > > > > >>> >> Best regards,
> > > > > > >>> >>
> > > > > > >>> >> --Daniil
> > > > > > >>> >>
> > > > > > >>> >> *From: *JC Beyler<
> ***@google.com>
> > > > > > >>> >> *Date: *Thursday,
> October 11, 2018 at 7:17 PM
> > > > > > >>> >> *To: *<
> ***@oracle.com>
> > > > > > >>> >> *Cc: *<
> serviceability-***@openjdk.java.net>
> > > > > > >>> >> *Subject: *Re:
> RFR 8211736: jdb doesn't print prompt when
> > > > > > >>> breakpoint
> > > > > > >>> >> is hit and
> suspend policy is STOP_EVENT_THREAD
> > > > > > >>> >>
> > > > > > >>> >> Hi Daniil,
> > > > > > >>> >>
> > > > > > >>> >> Looks good to me.
> I saw a really small nit:
> > > > > > >>> >>
> > > > > > >>> >>
> > > > > > >>>
> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
> > > > > > >>>
> > > > > > >>> >>
> > > > > > >>> <
> http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
> >
> > > > > > >>>
> > > > > > >>> >>
> > > > > > >>> >> 70
> jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS
> > > > > > >>> ,bpLine));
> > > > > > >>> >>
> > > > > > >>> >> There is a space
> after the '('.
> > > > > > >>> >>
> > > > > > >>> >> No need to send a
> new webrev for that evidently :),
> > > > > > >>> >>
> > > > > > >>> >> Jc
> > > > > > >>> >>
> > > > > > >>> >> On Thu, Oct 11,
> 2018 at 5:07 PM Daniil Titov
> > > > > > >>> >> <
> ***@oracle.com
> > > > > > >>> <mailto:
> ***@oracle.com>> wrote:
> > > > > > >>> >>
> > > > > > >>> >> Please review
> the change that fixes the issue with
> > > > > > >>> missing prompt
> > > > > > >>> >> in jdb when a
> breakpoint is hit and the suspend policy
> > > > > > >>> is set to
> > > > > > >>> >> stop the
> thread only.
> > > > > > >>> >>
> > > > > > >>> >> Webrev:
> > > > > > >>>
> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
> > > > > > >>> >> <
> http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
> > > > > > >>> >> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8211736
> > > > > > >>> >>
> > > > > > >>> >> Thanks!
> > > > > > >>> >> --Daniil
> > > > > > >>> >>
> > > > > > >>> >>
> > > > > > >>> >>
> > > > > > >>> >> --
> > > > > > >>> >>
> > > > > > >>> >> Thanks,
> > > > > > >>> >>
> > > > > > >>> >> Jc
> > > > > > >>> >>
> > > > > > >>> >
> > > > > > >>>
> > > > > > >>>
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>


--

Thanks,
Jc
Gary Adams
2018-10-23 00:46:41 UTC
Permalink
Ok by me


Sent from my iPad

> On Oct 22, 2018, at 8:26 PM, Daniil Titov <***@oracle.com> wrote:
>
> Thank you, Chris for reviewing this change!
>
> Alex, JC, Garry could you please say are you OK with this version of the webrev?
>
> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>
> Best regards,
> Daniil
>
> On 10/22/18, 11:18 AM, "Chris Plummer" <***@oracle.com> wrote:
>
> Hi Daniil,
>
> Looks good.
>
> thanks,
>
> Chris
>
>> On 10/19/18 4:01 PM, Daniil Titov wrote:
>> Hi Chris,
>>
>> Please review an updated version of the fix that makes the tests to use a custom pattern while waiting for the command to complete.
>>
>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>
>> Thanks!
>> --Daniil
>>
>>
>> On 10/19/18, 12:55 PM, "Chris Plummer" <***@oracle.com> wrote:
>>
>>> On 10/19/18 9:47 AM, Daniil Titov wrote:
>>> Hi Gary and Chris,
>>>
>>> I am resending the previous email since the table in that email got corrupted.
>>>
>>> Below is what output jdb prints when a breakpoint is hit depending on what suspended policy is used:
>>>
>>> The current behavior.
>>> SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed
>>> SUSPEND_EVENT_THREAD: Prompt is not printed, location is not printed
>>> SUSPEND_NONE: Prompt is not printed, location is not printed
>>>
>>> The fix changes this behavior as the following:
>>>
>>> SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed
>>> SUSPEND_EVENT_THREAD: Prompt is printed ( "> "), location is printed
>>> SUSPEND_NONE: Prompt is printed ( "> "), location is printed
>> I'm still in favor of this fix.
>>>
>>>
>>> Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"?
>>>
>>> Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here...
>> Maybe we need a version of command() that takes a pattern to look for
>> other than the prompt.
>>
>> Chris
>>>
>>>
>>> Thanks!
>>> --Daniil
>>>
>>> On 10/19/18, 9:27 AM, "Daniil Titov" <***@oracle.com> wrote:
>>>
>>> Hi Gary and Chris,
>>>
>>> Below is the table that shows what jdb output is printed when a breakpoint is hit depending on what suspended policy is used:
>>>
>>> SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED
>>> --------------------------------------- |---------------------------|--------------------------
>>> SUSPEND_ALL. | yes, e.g. "main[1]" | yes
>>> --------------------------------------- |-------------------------- |--------------------------
>>> SUSPEND_EVENT_THREAD | no | no
>>> ----------------------------------------|------------------------ --|--------------------------
>>> SUSPEND_ALL. | no | no
>>>
>>>
>>> The fix changes this behavior as the following:
>>>
>>> SUSPEND POLICY | PROMPT PRINTED. | LOCATION PRINTED
>>> --------------------------------------- |----------------------------|--------------------------
>>> SUSPEND_ALL. | yes , e.g. "main[1]" | yes
>>> --------------------------------------- |----------------------------|--------------------------
>>> SUSPEND_EVENT_THREAD | yes , ">" | yes
>>> ----------------------------------------|--------------------------- |--------------------------
>>> SUSPEND_ALL. | yes, ">". | yes
>>>
>>> Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"?
>>>
>>> Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (&gt;&nbsp; ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here...
>>>
>>>
>>> Thanks!
>>>
>>> Best regards,
>>> Daniil
>>>
>>>
>>>
>>> On 10/19/18, 12:54 AM, "***@oracle.com" <***@oracle.com> wrote:
>>>
>>> It's not clear to me if the omitted location information for the non
>>> stopping
>>> cases was intentional or not. It may be sufficient to know that the
>>> event fired
>>> without the extra information.
>>>
>>> I don't think a settable prompt is required either. There are plenty of
>>> jdb commands that
>>> could be used with the wait for message in tests that need to
>>> synchronize at a specific
>>> point in the test sequence.
>>>
>>> I don't think we see wait for simple prompt in any of the tests, because it
>>> is not reliable enough.
>>>
>>>> On 10/18/18 11:53 AM, Daniil Titov wrote:
>>>> Hi Gary,
>>>>
>>>> Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach?
>>>>
>>>> Thanks!
>>>>
>>>> Best regards,
>>>> Daniil
>>>>
>>>>
>>>>
>>>> On 10/18/18, 4:09 AM, "Gary Adams" <***@oracle.com> wrote:
>>>>
>>>> I'm not certain that we should be printing locations or prompts for
>>>> events when the vm has not been suspended. This looks OK for the
>>>> simple test case we are working on here, but in real life there may
>>>> be a lot more output produced.
>>>>
>>>> The user has to select a specific thread before additional commands
>>>> can be performed in the correct context. e.g. threads, thread n, where, ...
>>>> So the information is available to the user. It doesn't have to be
>>>> produced at the time the event is processed.
>>>>
>>>> I'm uncomfortable putting too much trust in waiting for the simple prompt,
>>>> because there is too great a chance of false positives on such a small
>>>> marker.
>>>>
>>>>
>>>>> On 10/17/18, 8:50 PM, Daniil Titov wrote:
>>>>> Hi Chris, Alex and JC,
>>>>>
>>>>> I created a separate issue to deal with "non-atomic" jdb output at https://bugs.openjdk.java.net/browse/JDK-8212626 .
>>>>>
>>>>> Please review an updated fix that includes the changes Alex suggested.
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.04
>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>>>>
>>>>> Thanks!
>>>>> --Daniil
>>>>>
>>>>>
>>>>> On 10/17/18, 5:06 PM, "Daniil Titov"<***@oracle.com> wrote:
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>> The previous email was accidentally fired before I managed to type anything in. Sorry for confusion.
>>>>>
>>>>> Jdb constantly reads new commands from System.in despite whether the breakpoint is hit and/or the prompt is printed.
>>>>>
>>>>> cat -n src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
>>>>>
>>>>> 786 // Process interactive commands.
>>>>> 787 MessageOutput.printPrompt();
>>>>> 788 while (true) {
>>>>> 789 String ln = in.readLine();
>>>>> 790 if (ln == null) {
>>>>> 791 /*
>>>>> 792 * Jdb is being shutdown because debuggee exited, ignore any 'null'
>>>>> 793 * returned by readLine() during shutdown. JDK-8154144.
>>>>> 794 */
>>>>> 795 if (!isShuttingDown()) {
>>>>> 796 MessageOutput.println("Input stream closed.");
>>>>> 797 }
>>>>> 798 ln = "quit";
>>>>> 799 }
>>>>> 800
>>>>> 801 if (ln.startsWith("!!")&& lastLine != null) {
>>>>> 802 ln = lastLine + ln.substring(2);
>>>>> 803 MessageOutput.printDirectln(ln);// Special case: use printDirectln()
>>>>> 804 }
>>>>> 805
>>>>> 806 StringTokenizer t = new StringTokenizer(ln);
>>>>> 807 if (t.hasMoreTokens()) {
>>>>> 808 lastLine = ln;
>>>>> 809 executeCommand(t);
>>>>> 810 } else {
>>>>> 811 MessageOutput.printPrompt();
>>>>> 812 }
>>>>> 813 }
>>>>> 814 } catch (VMDisconnectedException e) {
>>>>> 815 handler.handleDisconnectedException();
>>>>> 816 }
>>>>>
>>>>> Below is a sample debug session for the following test class that sends commands "threads" and "quit"
>>>>> 1 public class LoopTest {
>>>>> 2 public static void main(String[] args) throws Exception {
>>>>> 3 Thread thread = Thread.currentThread();
>>>>> 4 while(true) {
>>>>> 5 print(thread);
>>>>> 6 Thread.sleep(5000);
>>>>> 7 }
>>>>> 8 }
>>>>> 9
>>>>> 10 public static void print(Object obj) {
>>>>> 11 //System.out.println(obj);
>>>>> 12 }
>>>>> 13 }
>>>>>
>>>>> datitov-mac:work datitov$ ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest
>>>>> Initializing jdb ...
>>>>>> stop go at LoopTest:6
>>>>> Deferring breakpoint LoopTest:6.
>>>>> It will be set after the class is loaded.
>>>>>> run
>>>>> run LoopTest
>>>>> Set uncaught java.lang.Throwable
>>>>> Set deferred uncaught java.lang.Throwable
>>>>>>
>>>>> VM Started: Set deferred breakpoint LoopTest:6
>>>>>
>>>>> Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
>>>>> 6 Thread.sleep(5000);
>>>>>
>>>>> Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
>>>>> 6 Thread.sleep(5000);
>>>>> 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 sleeping
>>>>> Group InnocuousThreadGroup:
>>>>> (jdk.internal.misc.InnocuousThread)0x197 Common-Cleaner cond. waiting
>>>>>>
>>>>> Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
>>>>> 6 Thread.sleep(5000);
>>>>>
>>>>> Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
>>>>> 6 Thread.sleep(5000);
>>>>> quit
>>>>> Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
>>>>> 6 Thread.sleep(5000);
>>>>>
>>>>> datitov-mac:work datitov$
>>>>>
>>>>> I think we could print a simple prompt in this case as Alex suggested.
>>>>>
>>>>> Best regards,
>>>>> Daniil
>>>>>
>>>>> On 10/17/18, 3:52 PM, "Chris Plummer"<***@oracle.com> wrote:
>>>>>
>>>>> What is the jdb state for a breakpoint with SUSPEND_NONE? Can you
>>>>> actually type in commands even though no threads are suspended?
>>>>>
>>>>> Chris
>>>>>
>>>>>> On 10/17/18 3:31 PM, Alex Menkov wrote:
>>>>>> Hi Daniil, Chris,
>>>>>>
>>>>>> As far as I understand, the fix does not completely fixes all
>>>>>> "non-atomic" output issues (at least TTY.executeCommand still prints
>>>>>> prompt separately), so I agree that handle it as separate issue would
>>>>>> be better.
>>>>>> Unfortunately I don't know Gary's ideas for the issue.
>>>>>>
>>>>>> About the fix for print prompt:
>>>>>> 1) TTY.java:
>>>>>> + // Print current location if suspend policy is SUSPEND_NONE
>>>>>> I suppose you mean "Print breakpoint location"
>>>>>>
>>>>>> 2) Does it make sense to use printCurrentLocation for
>>>>>> SUSPEND_EVENT_THREAD?
>>>>>> Is it expected to print something different from printBreakpointLocation?
>>>>>>
>>>>>> 3) I don't quite understand why we don't print simple prompt for
>>>>>> SUSPEND_NONE. IIUC jdb can accept new command in both
>>>>>> SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb
>>>>>> waits for next command, right?)
>>>>>>
>>>>>> 4) JdbStopThreadTest.java
>>>>>> New line line in Java regexp is "\\R"
>>>>>>
>>>>>> --alex
>>>>>>
>>>>>>> On 10/17/2018 10:47, Chris Plummer wrote:
>>>>>>> Hi Alex,
>>>>>>>
>>>>>>> I think the tty buffering should be a separate bug fix, and I'd also
>>>>>>> like input from Gary on it since he had tried something similar at
>>>>>>> one point. It should probably also include a multithread test to
>>>>>>> prove the fix is working (after first getting the test to fail
>>>>>>> without the changes).
>>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>>> On 10/16/18 8:59 PM, Daniil Titov wrote:
>>>>>>>> Hi Alex, Chris and JC,
>>>>>>>>
>>>>>>>> Please review an updated version of the patch that addresses these
>>>>>>>> issues.
>>>>>>>>
>>>>>>>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>> --Daniil
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/12/18, 9:52 AM, "Alex Menkov"<***@oracle.com> wrote:
>>>>>>>>
>>>>>>>> Hi Daniil,
>>>>>>>> 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL
>>>>>>>> 2) wrong indent in JdbStopThreadTest.java:
>>>>>>>> 36 import lib.jdb.JdbCommand;
>>>>>>>> 37 import lib.jdb.JdbTest;
>>>>>>>> 3) I think it would be better to make waitForSimplePrompt
>>>>>>>> property of
>>>>>>>> JdbCommand (like JdbCommand.allowExit)
>>>>>>>> jdb.command(JdbCommand.run().replyIsSimplePrompt());
>>>>>>>> looks much clearer than
>>>>>>>> jdb.command(JdbCommand.run(), true);
>>>>>>>> 4) (TTY.java)
>>>>>>>> MessageOutput.lnprint("Breakpoint hit:");
>>>>>>>> + // Print current location and prompt if suspend policy is
>>>>>>>> SUSPEND_EVENT_THREAD.
>>>>>>>> + // In case of SUSPEND_ALL policy this is handled by
>>>>>>>> vmInterrupted()
>>>>>>>> method.
>>>>>>>> + if (be.request().suspendPolicy() ==
>>>>>>>> EventRequest.SUSPEND_EVENT_THREAD) {
>>>>>>>> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
>>>>>>>> + MessageOutput.printPrompt();
>>>>>>>> + }
>>>>>>>> We have 3 separate outputs.
>>>>>>>> If we have several concurrent threads, we can easy get mess of
>>>>>>>> outputs
>>>>>>>> from different threads.
>>>>>>>> I think it would be better to print everything in a single chunk.
>>>>>>>> I suppose TTY has other places with similar "non-atomic"
>>>>>>>> output, so
>>>>>>>> maybe revising TTY output should be handled by separate issue.
>>>>>>>> --alex
>>>>>>>>> On 10/11/2018 22:00, Chris Plummer wrote:
>>>>>>>>> Hi Daniil,
>>>>>>>>>
>>>>>>>>> Can you send output from an example jdb session?
>>>>>>>>>
>>>>>>>>> Do you think maybe we should also call printCurrentLocation()
>>>>>>>> when the
>>>>>>>>> suspend policy is NONE?
>>>>>>>>>
>>>>>>>>> There's a typo in the following line. The space is on the
>>>>>>>> wrong side of
>>>>>>>>> the comma.
>>>>>>>>>
>>>>>>>>> 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
>>>>>>>> ,bpLine));
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>>
>>>>>>>>> Chris
>>>>>>>>>
>>>>>>>>>> On 10/11/18 8:02 PM, Daniil Titov wrote:
>>>>>>>>>>
>>>>>>>>>> Thank you, JC!
>>>>>>>>>>
>>>>>>>>>> Please review an updated version of the patch that fixes
>>>>>>>> newly added
>>>>>>>>>> test for Windows platform (now it uses system dependent line
>>>>>>>>>> separator string).
>>>>>>>>>>
>>>>>>>>>> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
>>>>>>>>>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
>>>>>>>>>>
>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>
>>>>>>>>>> --Daniil
>>>>>>>>>>
>>>>>>>>>> *From: *JC Beyler<***@google.com>
>>>>>>>>>> *Date: *Thursday, October 11, 2018 at 7:17 PM
>>>>>>>>>> *To: *<***@oracle.com>
>>>>>>>>>> *Cc: *<serviceability-***@openjdk.java.net>
>>>>>>>>>> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when
>>>>>>>> breakpoint
>>>>>>>>>> is hit and suspend policy is STOP_EVENT_THREAD
>>>>>>>>>>
>>>>>>>>>> Hi Daniil,
>>>>>>>>>>
>>>>>>>>>> Looks good to me. I saw a really small nit:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
>>>>>>>>
>>>>>>>>>>
>>>>>>>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS
>>>>>>>> ,bpLine));
>>>>>>>>>>
>>>>>>>>>> There is a space after the '('.
>>>>>>>>>>
>>>>>>>>>> No need to send a new webrev for that evidently :),
>>>>>>>>>>
>>>>>>>>>> Jc
>>>>>>>>>>
>>>>>>>>>> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
>>>>>>>>>> <***@oracle.com
>>>>>>>> <mailto:***@oracle.com>> wrote:
>>>>>>>>>>
>>>>>>>>>> Please review the change that fixes the issue with
>>>>>>>> missing prompt
>>>>>>>>>> in jdb when a breakpoint is hit and the suspend policy
>>>>>>>> is set to
>>>>>>>>>> stop the thread only.
>>>>>>>>>>
>>>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
>>>>>>>>>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>> --Daniil
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Jc
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
>
>
>
Alex Menkov
2018-10-19 17:20:15 UTC
Permalink
Hi Gary,

Just want to remind that jdb is a tool for developers, not a tool for
testing.

On 10/19/2018 00:54, ***@oracle.com wrote:
> It's not clear to me if the omitted location information for the non
> stopping
> cases was intentional or not. It may be sufficient to know that the
> event fired
> without the extra information.

A single breakpoint is not a common case. Usually you have a number of
breakpoints in the debuggee.
Note also that currently jdb prints "Breakpoint hit: " only (and colon
at the end shows that extra info is expected to be printed).

>
> I don't think a settable prompt is required either. There are plenty of
> jdb commands that
> could be used with the wait for message in tests that need to
> synchronize at a specific
> point in the test sequence.

Once again - this is a tool for humans, and show prompt when user input
is expected is a good UI practice.

--alex

>
> I don't think we see wait for simple prompt in any of the tests, because it
> is not reliable enough.
>
> On 10/18/18 11:53 AM, Daniil Titov wrote:
>> Hi Gary,
>>
>> Currently when a breakpoint is hit the message "Breakpoint hit:" is
>> printed in the debugger output. What we do in this fix we just add
>> more information about what exact breakpoint is hit. Do you suggest we
>> should not print this line at all if suspend policy is SUSPEND_NONE?
>> If so then it is not clear what is the use of the command "stop go
>> ..." would be. Regarding waiting for the simple prompt, we could
>> change JDbCommand to have a field to store a prompt pattern and use
>> this pattern (if it was set) when waiting for command to complete. In
>> tests when required we would set the pattern in JdbCommand to more
>> complicated one matching a specific output we are expecting at this
>> particular step. Do you think it would be a better approach?
>>
>> Thanks!
>>
>> Best regards,
>> Daniil
>>
>>
>>
>> On 10/18/18, 4:09 AM, "Gary Adams" <***@oracle.com> wrote:
>>
>>      I'm not certain that we should be printing locations or prompts for
>>      events when the vm has not been suspended. This looks OK for the
>>      simple test case we are working on here, but in real life there may
>>      be a lot more output produced.
>>      The user has to select a specific thread before additional commands
>>      can be performed in the correct context. e.g. threads, thread n,
>> where, ...
>>      So the information is available to the user. It doesn't have to be
>>      produced at the time the event is processed.
>>      I'm uncomfortable putting too much trust in waiting for the
>> simple prompt,
>>      because there is too great a chance of false positives on such a
>> small
>>      marker.
>>      On 10/17/18, 8:50 PM, Daniil Titov wrote:
>>      > Hi Chris, Alex and JC,
>>      >
>>      > I created a separate issue to deal with "non-atomic" jdb output
>> at https://bugs.openjdk.java.net/browse/JDK-8212626 .
>>      >
>>      > Please review an updated fix that includes the changes Alex
>> suggested.
>>      >
>>      > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.04
>>      > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>      >
>>      > Thanks!
>>      > --Daniil
>>      >
>>      >
>>      > On 10/17/18, 5:06 PM, "Daniil
>> Titov"<***@oracle.com>  wrote:
>>      >
>>      >      Hi Chris,
>>      >
>>      >      The previous email was accidentally fired before I managed
>> to type anything in. Sorry for confusion.
>>      >
>>      >      Jdb constantly reads new commands from System.in despite
>> whether the breakpoint is hit and/or the prompt is printed.
>>      >
>>      >      cat -n
>> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
>>      >
>>      >      786                // Process interactive commands.
>>      >         787                MessageOutput.printPrompt();
>>      >         788                while (true) {
>>      >         789                    String ln = in.readLine();
>>      >         790                    if (ln == null) {
>>      >         791                        /*
>>      >         792                         *  Jdb is being shutdown
>> because debuggee exited, ignore any 'null'
>>      >         793                         *  returned by readLine()
>> during shutdown. JDK-8154144.
>>      >         794                         */
>>      >         795                        if (!isShuttingDown()) {
>>      >         796
>> MessageOutput.println("Input stream closed.");
>>      >         797                        }
>>      >         798                        ln = "quit";
>>      >         799                    }
>>      >         800
>>      >         801                    if (ln.startsWith("!!")&&
>> lastLine != null) {
>>      >         802                        ln = lastLine +
>> ln.substring(2);
>>      >         803
>> MessageOutput.printDirectln(ln);// Special case: use printDirectln()
>>      >         804                    }
>>      >         805
>>      >         806                    StringTokenizer t = new
>> StringTokenizer(ln);
>>      >         807                    if (t.hasMoreTokens()) {
>>      >         808                        lastLine = ln;
>>      >         809                        executeCommand(t);
>>      >         810                    } else {
>>      >         811                        MessageOutput.printPrompt();
>>      >         812                    }
>>      >         813                }
>>      >         814            } catch (VMDisconnectedException e) {
>>      >         815                handler.handleDisconnectedException();
>>      >         816            }
>>      >
>>      >      Below is a sample debug session for the following test
>> class that sends commands "threads" and "quit"
>>      >      1    public class LoopTest {
>>      >           2        public static void main(String[] args)
>> throws Exception {
>>      >           3            Thread thread = Thread.currentThread();
>>      >           4            while(true) {
>>      >           5                print(thread);
>>      >           6                Thread.sleep(5000);
>>      >           7            }
>>      >           8        }
>>      >           9
>>      >          10        public static void print(Object obj) {
>>      >          11            //System.out.println(obj);
>>      >          12        }
>>      >          13    }
>>      >
>>      >      datitov-mac:work datitov$
>> ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest
>>      >      Initializing jdb ...
>>      >      >  stop go at LoopTest:6
>>      >      Deferring breakpoint LoopTest:6.
>>      >      It will be set after the class is loaded.
>>      >      >  run
>>      >      run LoopTest
>>      >      Set uncaught java.lang.Throwable
>>      >      Set deferred uncaught java.lang.Throwable
>>      >      >
>>      >      VM Started: Set deferred breakpoint LoopTest:6
>>      >
>>      >      Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
>>      >      6                Thread.sleep(5000);
>>      >
>>      >      Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
>>      >      6                Thread.sleep(5000);
>>      >      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              sleeping
>>      >      Group InnocuousThreadGroup:
>>      >        (jdk.internal.misc.InnocuousThread)0x197
>> Common-Cleaner    cond. waiting
>>      >      >
>>      >      Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
>>      >      6                Thread.sleep(5000);
>>      >
>>      >      Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
>>      >      6                Thread.sleep(5000);
>>      >      quit
>>      >      Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8
>>      >      6                Thread.sleep(5000);
>>      >
>>      >      datitov-mac:work datitov$
>>      >
>>      >      I think we could print a simple prompt in this case as
>> Alex suggested.
>>      >
>>      >      Best regards,
>>      >      Daniil
>>      >
>>      >      On 10/17/18, 3:52 PM, "Chris
>> Plummer"<***@oracle.com>  wrote:
>>      >
>>      >          What is the jdb state for a breakpoint with
>> SUSPEND_NONE? Can you
>>      >          actually type in commands even though no threads are
>> suspended?
>>      >
>>      >          Chris
>>      >
>>      >          On 10/17/18 3:31 PM, Alex Menkov wrote:
>>      >          >  Hi Daniil, Chris,
>>      >          >
>>      >          >  As far as I understand, the fix does not completely
>> fixes all
>>      >          >  "non-atomic" output issues (at least
>> TTY.executeCommand still prints
>>      >          >  prompt separately), so I agree that handle it as
>> separate issue would
>>      >          >  be better.
>>      >          >  Unfortunately I don't know Gary's ideas for the issue.
>>      >          >
>>      >          >  About the fix for print prompt:
>>      >          >  1) TTY.java:
>>      >          >  +            // Print current location if suspend
>> policy is SUSPEND_NONE
>>      >          >  I suppose you mean "Print breakpoint location"
>>      >          >
>>      >          >  2) Does it make sense to use printCurrentLocation for
>>      >          >  SUSPEND_EVENT_THREAD?
>>      >          >  Is it expected to print something different from
>> printBreakpointLocation?
>>      >          >
>>      >          >  3) I don't quite understand why we don't print
>> simple prompt for
>>      >          >  SUSPEND_NONE. IIUC jdb can accept new command in both
>>      >          >  SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt
>> shows that jdb
>>      >          >  waits for next command, right?)
>>      >          >
>>      >          >  4) JdbStopThreadTest.java
>>      >          >  New line line in Java regexp is "\\R"
>>      >          >
>>      >          >  --alex
>>      >          >
>>      >          >  On 10/17/2018 10:47, Chris Plummer wrote:
>>      >          >>  Hi Alex,
>>      >          >>
>>      >          >>  I think the tty buffering should be a separate bug
>> fix, and I'd also
>>      >          >>  like input from Gary on it since he had tried
>> something similar at
>>      >          >>  one point. It should probably also include a
>> multithread test to
>>      >          >>  prove the fix is working (after first getting the
>> test to fail
>>      >          >>  without the changes).
>>      >          >>
>>      >          >>  thanks,
>>      >          >>
>>      >          >>  Chris
>>      >          >>
>>      >          >>  On 10/16/18 8:59 PM, Daniil Titov wrote:
>>      >          >>>  Hi Alex, Chris and JC,
>>      >          >>>
>>      >          >>>  Please review an updated version of the patch
>> that addresses these
>>      >          >>>  issues.
>>      >          >>>
>>      >          >>>  Webrev:
>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
>>      >          >>>  Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8211736
>>      >          >>>
>>      >          >>>  Thanks!
>>      >          >>>  --Daniil
>>      >          >>>
>>      >          >>>
>>      >          >>>  On 10/12/18, 9:52 AM, "Alex
>> Menkov"<***@oracle.com>  wrote:
>>      >          >>>
>>      >          >>>       Hi Daniil,
>>      >          >>>       1) +1 for printCurrentLocation when
>> suspendPolicy != SUSPEND_ALL
>>      >          >>>       2) wrong indent in JdbStopThreadTest.java:
>>      >          >>>          36         import lib.jdb.JdbCommand;
>>      >          >>>          37         import lib.jdb.JdbTest;
>>      >          >>>       3) I think it would be better to make
>> waitForSimplePrompt
>>      >          >>>  property of
>>      >          >>>       JdbCommand (like JdbCommand.allowExit)
>>      >          >>>
>> jdb.command(JdbCommand.run().replyIsSimplePrompt());
>>      >          >>>       looks much clearer than
>>      >          >>>       jdb.command(JdbCommand.run(), true);
>>      >          >>>       4) (TTY.java)
>>      >          >>>           MessageOutput.lnprint("Breakpoint hit:");
>>      >          >>>       +  // Print current location and prompt if
>> suspend policy is
>>      >          >>>       SUSPEND_EVENT_THREAD.
>>      >          >>>       +  // In case of SUSPEND_ALL policy this is
>> handled by
>>      >          >>>  vmInterrupted()
>>      >          >>>       method.
>>      >          >>>       +  if (be.request().suspendPolicy() ==
>>      >          >>>  EventRequest.SUSPEND_EVENT_THREAD) {
>>      >          >>>       +
>> printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
>>      >          >>>       +      MessageOutput.printPrompt();
>>      >          >>>       +  }
>>      >          >>>       We have 3 separate outputs.
>>      >          >>>       If we have several concurrent threads, we
>> can easy get mess of
>>      >          >>>  outputs
>>      >          >>>       from different threads.
>>      >          >>>       I think it would be better to print
>> everything in a single chunk.
>>      >          >>>       I suppose TTY has other places with similar
>> "non-atomic"
>>      >          >>>  output, so
>>      >          >>>       maybe revising TTY output should be handled
>> by separate issue.
>>      >          >>>       --alex
>>      >          >>>       On 10/11/2018 22:00, Chris Plummer wrote:
>>      >          >>>       >  Hi Daniil,
>>      >          >>>       >
>>      >          >>>       >  Can you send output from an example jdb
>> session?
>>      >          >>>       >
>>      >          >>>       >  Do you think maybe we should also call
>> printCurrentLocation()
>>      >          >>>  when the
>>      >          >>>       >  suspend policy is NONE?
>>      >          >>>       >
>>      >          >>>       >  There's a typo in the following line. The
>> space is on the
>>      >          >>>  wrong side of
>>      >          >>>       >  the comma.
>>      >          >>>       >
>>      >          >>>       >     72
>> jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
>>      >          >>>  ,bpLine));
>>      >          >>>       >
>>      >          >>>       >  thanks,
>>      >          >>>       >
>>      >          >>>       >  Chris
>>      >          >>>       >
>>      >          >>>       >  On 10/11/18 8:02 PM, Daniil Titov wrote:
>>      >          >>>       >>
>>      >          >>>       >>  Thank you,  JC!
>>      >          >>>       >>
>>      >          >>>       >>  Please review an updated version of the
>> patch that fixes
>>      >          >>>  newly added
>>      >          >>>       >>  test for Windows platform  (now it uses
>> system dependent line
>>      >          >>>       >>  separator string).
>>      >          >>>       >>
>>      >          >>>       >>
>> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
>>      >          >>>       >>
>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
>>      >          >>>       >>
>>      >          >>>       >>  Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8211736
>>      >          >>>       >>
>>      >          >>>       >>  Best regards,
>>      >          >>>       >>
>>      >          >>>       >>  --Daniil
>>      >          >>>       >>
>>      >          >>>       >>  *From: *JC Beyler<***@google.com>
>>      >          >>>       >>  *Date: *Thursday, October 11, 2018 at
>> 7:17 PM
>>      >          >>>       >>  *To: *<***@oracle.com>
>>      >          >>>       >>  *Cc: *<serviceability-***@openjdk.java.net>
>>      >          >>>       >>  *Subject: *Re: RFR 8211736: jdb doesn't
>> print prompt when
>>      >          >>>  breakpoint
>>      >          >>>       >>  is hit and suspend policy is
>> STOP_EVENT_THREAD
>>      >          >>>       >>
>>      >          >>>       >>  Hi Daniil,
>>      >          >>>       >>
>>      >          >>>       >>  Looks good to me. I saw a really small nit:
>>      >          >>>       >>
>>      >          >>>       >>
>>      >          >>>
>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
>>
>>      >          >>>
>>      >          >>>       >>
>>      >          >>>
>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
>>
>>      >          >>>
>>      >          >>>       >>
>>      >          >>>       >>  70  jdb.command(JdbCommand.stopThreadAt(
>> DEBUGGEE_CLASS
>>      >          >>>  ,bpLine));
>>      >          >>>       >>
>>      >          >>>       >>  There is a space after the '('.
>>      >          >>>       >>
>>      >          >>>       >>  No need to send a new webrev for that
>> evidently :),
>>      >          >>>       >>
>>      >          >>>       >>  Jc
>>      >          >>>       >>
>>      >          >>>       >>  On Thu, Oct 11, 2018 at 5:07 PM Daniil
>> Titov
>>      >          >>>       >>  <***@oracle.com
>>      >          >>>  <mailto:***@oracle.com>>  wrote:
>>      >          >>>       >>
>>      >          >>>       >>      Please review the change that fixes
>> the issue with
>>      >          >>>  missing prompt
>>      >          >>>       >>      in jdb when a breakpoint is hit and
>> the suspend policy
>>      >          >>>  is set to
>>      >          >>>       >>      stop the thread only.
>>      >          >>>       >>
>>      >          >>>       >>      Webrev:
>>      >          >>>  http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
>>      >          >>>       >>
>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
>>      >          >>>       >>      Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8211736
>>      >          >>>       >>
>>      >          >>>       >>      Thanks!
>>      >          >>>       >>      --Daniil
>>      >          >>>       >>
>>      >          >>>       >>
>>      >          >>>       >>
>>      >          >>>       >>  --
>>      >          >>>       >>
>>      >          >>>       >>  Thanks,
>>      >          >>>       >>
>>      >          >>>       >>  Jc
>>      >          >>>       >>
>>      >          >>>       >
>>      >          >>>
>>      >          >>>
>>      >          >>
>>      >          >>
>>      >
>>      >
>>      >
Chris Plummer
2018-10-19 19:50:53 UTC
Permalink
Chris Plummer
2018-10-17 22:51:03 UTC
Permalink
Sorry, I meant to address Daniil, not Alex. Sorry about any confusion.

Chris

On 10/17/18 10:47 AM, Chris Plummer wrote:
> Hi Alex,
>
> I think the tty buffering should be a separate bug fix, and I'd also
> like input from Gary on it since he had tried something similar at one
> point. It should probably also include a multithread test to prove the
> fix is working (after first getting the test to fail without the
> changes).
>
> thanks,
>
> Chris
>
> On 10/16/18 8:59 PM, Daniil Titov wrote:
>> Hi Alex, Chris and JC,
>>
>> Please review an updated version of the patch that addresses these
>> issues.
>>
>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
>> Issue:  https://bugs.openjdk.java.net/browse/JDK-8211736
>>
>> Thanks!
>> --Daniil
>>
>>
>> On 10/12/18, 9:52 AM, "Alex Menkov" <***@oracle.com> wrote:
>>
>>      Hi Daniil,
>>           1) +1 for printCurrentLocation when suspendPolicy !=
>> SUSPEND_ALL
>>           2) wrong indent in JdbStopThreadTest.java:
>>         36         import lib.jdb.JdbCommand;
>>         37         import lib.jdb.JdbTest;
>>           3) I think it would be better to make waitForSimplePrompt
>> property of
>>      JdbCommand (like JdbCommand.allowExit)
>>           jdb.command(JdbCommand.run().replyIsSimplePrompt());
>>      looks much clearer than
>>      jdb.command(JdbCommand.run(), true);
>>           4) (TTY.java)
>>          MessageOutput.lnprint("Breakpoint hit:");
>>      +  // Print current location and prompt if suspend policy is
>>      SUSPEND_EVENT_THREAD.
>>      +  // In case of SUSPEND_ALL policy this is handled by
>> vmInterrupted()
>>      method.
>>      +  if (be.request().suspendPolicy() ==
>> EventRequest.SUSPEND_EVENT_THREAD) {
>>      + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
>>      +      MessageOutput.printPrompt();
>>      +  }
>>      We have 3 separate outputs.
>>      If we have several concurrent threads, we can easy get mess of
>> outputs
>>      from different threads.
>>      I think it would be better to print everything in a single chunk.
>>      I suppose TTY has other places with similar "non-atomic" output, so
>>      maybe revising TTY output should be handled by separate issue.
>>           --alex
>>           On 10/11/2018 22:00, Chris Plummer wrote:
>>      > Hi Daniil,
>>      >
>>      > Can you send output from an example jdb session?
>>      >
>>      > Do you think maybe we should also call printCurrentLocation()
>> when the
>>      > suspend policy is NONE?
>>      >
>>      > There's a typo in the following line. The space is on the
>> wrong side of
>>      > the comma.
>>      >
>>      >    72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
>> ,bpLine));
>>      >
>>      > thanks,
>>      >
>>      > Chris
>>      >
>>      > On 10/11/18 8:02 PM, Daniil Titov wrote:
>>      >>
>>      >> Thank you,  JC!
>>      >>
>>      >> Please review an updated version of the patch that fixes
>> newly added
>>      >> test for Windows platform  (now it uses system dependent line
>>      >> separator string).
>>      >>
>>      >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
>>      >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
>>      >>
>>      >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>      >>
>>      >> Best regards,
>>      >>
>>      >> --Daniil
>>      >>
>>      >> *From: *JC Beyler <***@google.com>
>>      >> *Date: *Thursday, October 11, 2018 at 7:17 PM
>>      >> *To: *<***@oracle.com>
>>      >> *Cc: *<serviceability-***@openjdk.java.net>
>>      >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when
>> breakpoint
>>      >> is hit and suspend policy is STOP_EVENT_THREAD
>>      >>
>>      >> Hi Daniil,
>>      >>
>>      >> Looks good to me. I saw a really small nit:
>>      >>
>>      >>
>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
>>      >>
>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
>>      >>
>>      >> 70  jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS
>> ,bpLine));
>>      >>
>>      >> There is a space after the '('.
>>      >>
>>      >> No need to send a new webrev for that evidently :),
>>      >>
>>      >> Jc
>>      >>
>>      >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
>>      >> <***@oracle.com
>> <mailto:***@oracle.com>> wrote:
>>      >>
>>      >>     Please review the change that fixes the issue with
>> missing prompt
>>      >>     in jdb when a breakpoint is hit and the suspend policy is
>> set to
>>      >>     stop the thread only.
>>      >>
>>      >>     Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
>>      >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
>>      >>     Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>      >>
>>      >>     Thanks!
>>      >>     --Daniil
>>      >>
>>      >>
>>      >>
>>      >> --
>>      >>
>>      >> Thanks,
>>      >>
>>     
Gary Adams
2018-10-18 11:47:19 UTC
Permalink
Back in July, I tried to address the jdb output synchronization problem
by buffering the output from commands and events.

http://cr.openjdk.java.net/~gadams/8169718/webrev.01/

The changes were very invasive and only provided a partial solution.

Bottom line for me is the fact that the jdb commands, replies and prompts
were never designed as a rigid protocol. They were designed to be
interactive
with a user and guiding them through a debugging session.

The tests that process jdb commands are fragile, because they run
much quicker than user interactive speeds, so race conditions can be
observed.
Also, the reliance on a single standard output stream allows for
interspersed
output.

I think we are pretty close to reaching the current test stabilization
goals and
this area doesn't really merit additional investment at this time.

On 10/17/18, 1:47 PM, Chris Plummer wrote:
> Hi Alex,
>
> I think the tty buffering should be a separate bug fix, and I'd also
> like input from Gary on it since he had tried something similar at one
> point. It should probably also include a multithread test to prove the
> fix is working (after first getting the test to fail without the
> changes).
>
> thanks,
>
> Chris
>
> On 10/16/18 8:59 PM, Daniil Titov wrote:
>> Hi Alex, Chris and JC,
>>
>> Please review an updated version of the patch that addresses these
>> issues.
>>
>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>
>> Thanks!
>> --Daniil
>>
>>
>> On 10/12/18, 9:52 AM, "Alex Menkov" <***@oracle.com> wrote:
>>
>> Hi Daniil,
>> 1) +1 for printCurrentLocation when suspendPolicy !=
>> SUSPEND_ALL
>> 2) wrong indent in JdbStopThreadTest.java:
>> 36 import lib.jdb.JdbCommand;
>> 37 import lib.jdb.JdbTest;
>> 3) I think it would be better to make waitForSimplePrompt
>> property of
>> JdbCommand (like JdbCommand.allowExit)
>> jdb.command(JdbCommand.run().replyIsSimplePrompt());
>> looks much clearer than
>> jdb.command(JdbCommand.run(), true);
>> 4) (TTY.java)
>> MessageOutput.lnprint("Breakpoint hit:");
>> + // Print current location and prompt if suspend policy is
>> SUSPEND_EVENT_THREAD.
>> + // In case of SUSPEND_ALL policy this is handled by
>> vmInterrupted()
>> method.
>> + if (be.request().suspendPolicy() ==
>> EventRequest.SUSPEND_EVENT_THREAD) {
>> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
>> + MessageOutput.printPrompt();
>> + }
>> We have 3 separate outputs.
>> If we have several concurrent threads, we can easy get mess of
>> outputs
>> from different threads.
>> I think it would be better to print everything in a single chunk.
>> I suppose TTY has other places with similar "non-atomic" output, so
>> maybe revising TTY output should be handled by separate issue.
>> --alex
>> On 10/11/2018 22:00, Chris Plummer wrote:
>> > Hi Daniil,
>> >
>> > Can you send output from an example jdb session?
>> >
>> > Do you think maybe we should also call printCurrentLocation() when the
>> > suspend policy is NONE?
>> >
>> > There's a typo in the following line. The space is on the wrong
>> side of
>> > the comma.
>> >
>> > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS
>> ,bpLine));
>> >
>> > thanks,
>> >
>> > Chris
>> >
>> > On 10/11/18 8:02 PM, Daniil Titov wrote:
>> >>
>> >> Thank you, JC!
>> >>
>> >> Please review an updated version of the patch that fixes newly added
>> >> test for Windows platform (now it uses system dependent line
>> >> separator string).
>> >>
>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
>> >>
>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>> >>
>> >> Best regards,
>> >>
>> >> --Daniil
>> >>
>> >> *From: *JC Beyler <***@google.com>
>> >> *Date: *Thursday, October 11, 2018 at 7:17 PM
>> >> *To: *<***@oracle.com>
>> >> *Cc: *<serviceability-***@openjdk.java.net>
>> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when breakpoint
>> >> is hit and suspend policy is STOP_EVENT_THREAD
>> >>
>> >> Hi Daniil,
>> >>
>> >> Looks good to me. I saw a really small nit:
>> >>
>> >>
>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
>> >>
>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
>> >>
>> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS ,bpLine));
>> >>
>> >> There is a space after the '('.
>> >>
>> >> No need to send a new webrev for that evidently :),
>> >>
>> >> Jc
>> >>
>> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
>> >> <***@oracle.com <mailto:***@oracle.com>> wrote:
>> >>
>> >> Please review the change that fixes the issue with missing prompt
>> >> in jdb when a breakpoint is hit and the suspend policy is set to
>> >> stop the thread only.
>> >>
>> >> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>> >>
>> >> Thanks!
>> >> --Daniil
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> Thanks,
>> >>
>> >> Jc
>> >>
>> >
>>
>>
>
>
Chris Plummer
2018-10-18 17:27:05 UTC
Permalink
+1

On 10/18/18 4:47 AM, Gary Adams wrote:
> Back in July, I tried to address the jdb output synchronization problem
> by buffering the output from commands and events.
>
>   http://cr.openjdk.java.net/~gadams/8169718/webrev.01/
>
> The changes were very invasive and only provided a partial solution.
>
> Bottom line for me is the fact that the jdb commands, replies and prompts
> were never designed as a rigid protocol. They were designed to be
> interactive
> with a user and guiding them through a debugging session.
>
> The tests that process jdb commands are fragile, because they run
> much quicker than user interactive speeds, so race conditions can be
> observed.
> Also, the reliance on a single standard output stream allows for
> interspersed
> output.
>
> I think we are pretty close to reaching the current test stabilization
> goals and
> this area doesn't really merit additional investment at this time.
>
> On 10/17/18, 1:47 PM, Chris Plummer wrote:
>> Hi Alex,
>>
>> I think the tty buffering should be a separate bug fix, and I'd also
>> like input from Gary on it since he had tried something similar at
>> one point. It should probably also include a multithread test to
>> prove the fix is working (after first getting the test to fail
>> without the changes).
>>
>> thanks,
>>
>> Chris
>>
>> On 10/16/18 8:59 PM, Daniil Titov wrote:
>>> Hi Alex, Chris and JC,
>>>
>>> Please review an updated version of the patch that addresses these
>>> issues.
>>>
>>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
>>> Issue:  https://bugs.openjdk.java.net/browse/JDK-8211736
>>>
>>> Thanks!
>>> --Daniil
>>>
>>>
>>> On 10/12/18, 9:52 AM, "Alex Menkov" <***@oracle.com> wrote:
>>>
>>>      Hi Daniil,
>>>           1) +1 for printCurrentLocation when suspendPolicy !=
>>> SUSPEND_ALL
>>>           2) wrong indent in JdbStopThreadTest.java:
>>>         36         import lib.jdb.JdbCommand;
>>>         37         import lib.jdb.JdbTest;
>>>           3) I think it would be better to make waitForSimplePrompt
>>> property of
>>>      JdbCommand (like JdbCommand.allowExit)
>>>           jdb.command(JdbCommand.run().replyIsSimplePrompt());
>>>      looks much clearer than
>>>      jdb.command(JdbCommand.run(), true);
>>>           4) (TTY.java)
>>>          MessageOutput.lnprint("Breakpoint hit:");
>>>      +  // Print current location and prompt if suspend policy is
>>>      SUSPEND_EVENT_THREAD.
>>>      +  // In case of SUSPEND_ALL policy this is handled by
>>> vmInterrupted()
>>>      method.
>>>      +  if (be.request().suspendPolicy() ==
>>> EventRequest.SUSPEND_EVENT_THREAD) {
>>>      + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread()));
>>>      +      MessageOutput.printPrompt();
>>>      +  }
>>>      We have 3 separate outputs.
>>>      If we have several concurrent threads, we can easy get mess of
>>> outputs
>>>      from different threads.
>>>      I think it would be better to print everything in a single chunk.
>>>      I suppose TTY has other places with similar "non-atomic"
>>> output, so
>>>      maybe revising TTY output should be handled by separate issue.
>>>           --alex
>>>           On 10/11/2018 22:00, Chris Plummer wrote:
>>> > Hi Daniil,
>>> >
>>> > Can you send output from an example jdb session?
>>> >
>>> > Do you think maybe we should also call printCurrentLocation() when
>>> the
>>> > suspend policy is NONE?
>>> >
>>> > There's a typo in the following line. The space is on the wrong
>>> side of
>>> > the comma.
>>> >
>>> >    72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS ,bpLine));
>>> >
>>> > thanks,
>>> >
>>> > Chris
>>> >
>>> > On 10/11/18 8:02 PM, Daniil Titov wrote:
>>> >>
>>> >> Thank you,  JC!
>>> >>
>>> >> Please review an updated version of the patch that fixes newly added
>>> >> test for Windows platform  (now it uses system dependent line
>>> >> separator string).
>>> >>
>>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/
>>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/>
>>> >>
>>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>> >>
>>> >> Best regards,
>>> >>
>>> >> --Daniil
>>> >>
>>> >> *From: *JC Beyler <***@google.com>
>>> >> *Date: *Thursday, October 11, 2018 at 7:17 PM
>>> >> *To: *<***@oracle.com>
>>> >> *Cc: *<serviceability-***@openjdk.java.net>
>>> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when breakpoint
>>> >> is hit and suspend policy is STOP_EVENT_THREAD
>>> >>
>>> >> Hi Daniil,
>>> >>
>>> >> Looks good to me. I saw a really small nit:
>>> >>
>>> >>
>>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html
>>> >>
>>> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html>
>>> >>
>>> >> 70  jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS ,bpLine));
>>> >>
>>> >> There is a space after the '('.
>>> >>
>>> >> No need to send a new webrev for that evidently :),
>>> >>
>>> >> Jc
>>> >>
>>> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov
>>> >> <***@oracle.com <mailto:***@oracle.com>>
>>> wrote:
>>> >>
>>> >>     Please review the change that fixes the issue with missing
>>> prompt
>>> >>     in jdb when a breakpoint is hit and the suspend policy is set to
>>> >>     stop the thread only.
>>> >>
>>> >>     Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01
>>> >> <http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01>
>>> >>     Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>>> >>
>>> >>     Thanks!
>>> >>     --Daniil
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >>
>>> >> Thanks,
>>> >>
>>> >> Jc
>>> >>
>>> >
>>>
>>>
>>
>>
>
Loading...