PING: RFR: 8209790: SA tools not providing option to connect to debug server

Daniel D. Daugherty daniel.daugherty at oracle.com
Thu Jul 11 18:46:05 UTC 2019


Greetings,

The new test added by this fix has been failing in JDK14 CI:

JDK-8227594 sadebugd/DebugdConnectTest.java fails due to 
"java.rmi.NotBoundException: SARemoteDebugger"
https://bugs.openjdk.java.net/browse/JDK-8227594

The test failure has been happening in Tier[345] so I think
either Serguei or Chris P needs to check this out...

Dan



On 7/10/19 7:15 PM, Yasumasa Suenaga wrote:
> Thanks Serguei!
>
> Yasumasa
>
>
> On 2019/07/11 2:55, serguei.spitsyn at oracle.com wrote:
>> Hi Yasumasa,
>>
>> Thank you for adding your comment to the CSR!
>> It looks good to me.
>>
>> Thanks,
>> Serguei
>>
>>
>> On 7/9/19 18:20, Yasumasa Suenaga wrote:
>>> Hi Serguei,
>>>
>>> I added a comment that the change from the latest (approved) 
>>> proposal to the CSR. Could you check it again?
>>>
>>> Please tell me if it is not enough.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>>
>>> 2019年7月10日(水) 8:12 <serguei.spitsyn at oracle.com 
>>> <mailto:serguei.spitsyn at oracle.com>>:
>>>
>>>     Hi Yasumasa,
>>>
>>>     I'd like you to be more precise.
>>>     Providing the webrev, email exchange and saying about help 
>>> messages is
>>>     not precise.
>>>     It requires some non-trivial extra work.
>>>     Could you add a comment with this:
>>>       What help message has been changed to what?
>>>
>>>     Thanks,
>>>     Serguei
>>>
>>>     On 7/9/19 3:51 PM, Yasumasa Suenaga wrote:
>>>     > Hi Serguei,
>>>     >
>>>     > I added a comment to the CSR.
>>>     > I've updated help messages in Specification section of the CSR.
>>>     >
>>>     >
>>>     > Thanks,
>>>     >
>>>     > Yasumasa
>>>     >
>>>     >
>>>     > On 2019/07/10 7:42, serguei.spitsyn at oracle.com 
>>> <mailto:serguei.spitsyn at oracle.com> wrote:
>>>     >> Hi Yasumasa,
>>>     >>
>>>     >> Could you be more precise?
>>>     >> What was the latest change in this CSR?
>>>     >> Could you add it as a comment?
>>>     >> It will safe time for reviewers and approvers.
>>>     >>
>>>     >> Thanks,
>>>     >> Serguei
>>>     >>
>>>     >> On 7/9/19 3:35 PM, Yasumasa Suenaga wrote:
>>>     >>> Thanks Serguei!
>>>     >>>
>>>     >>> I reopened the CSR and update the description.
>>>     >>> Could you review again it?
>>>     >>>
>>>     >>> https://bugs.openjdk.java.net/browse/JDK-8224979
>>>     >>>
>>>     >>>
>>>     >>> Thanks,
>>>     >>>
>>>     >>> Yasumasa
>>>     >>>
>>>     >>>
>>>     >>> On 2019/07/10 4:11, serguei.spitsyn at oracle.com 
>>> <mailto:serguei.spitsyn at oracle.com> wrote:
>>>     >>>> Hi Yasumasa,
>>>     >>>>
>>>     >>>> The update looks Okay to me.
>>>     >>>>
>>>     >>>> Thanks,
>>>     >>>> Serguei
>>>     >>>>
>>>     >>>>
>>>     >>>> On 7/8/19 4:16 PM, Yasumasa Suenaga wrote:
>>>     >>>>> Thank you Chris!
>>>     >>>>>
>>>     >>>>> Serguei, do you agree with this change?
>>>     >>>>>
>>>     >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.07/
>>>     >>>>>
>>>     >>>>> If you are ok, I will reopen the CSR (JDK-8224979).
>>>     >>>>>
>>>     >>>>> 
>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-July/028624.html
>>>     >>>>>
>>>     >>>>>
>>>     >>>>>
>>>     >>>>> Thanks,
>>>     >>>>>
>>>     >>>>> Yasumasa
>>>     >>>>>
>>>     >>>>>
>>>     >>>>> On 2019/07/09 8:08, Chris Plummer wrote:
>>>     >>>>>> Looks good! Sorry about the high number of iterations. I 
>>> should
>>>     >>>>>> have caught some things sooner.
>>>     >>>>>>
>>>     >>>>>> thanks,
>>>     >>>>>>
>>>     >>>>>> Chris
>>>     >>>>>>
>>>     >>>>>> On 7/8/19 3:43 PM, Yasumasa Suenaga wrote:
>>>     >>>>>>> Hi Chris,
>>>     >>>>>>>
>>>     >>>>>>> Thank you for your comment.
>>>     >>>>>>> I fixed it in new webrev:
>>>     >>>>>>>
>>>     >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.07/
>>>     >>>>>>>
>>>     >>>>>>> Could you check again?
>>>     >>>>>>>
>>>     >>>>>>>
>>>     >>>>>>> Yasumasa
>>>     >>>>>>>
>>>     >>>>>>>
>>>     >>>>>>> On 2019/07/09 4:11, Chris Plummer wrote:
>>>     >>>>>>>> Hi Yasumasa,
>>>     >>>>>>>>
>>>     >>>>>>>> Sorry, just noticed one other thing:
>>>     >>>>>>>>
>>>     >>>>>>>>>     <--core --exe> and <--pid> and <--connect> are 
>>> mutually
>>>     >>>>>>>>> exclusive.
>>>     >>>>>>>> I'm not sure why you are using angled brackets here. 
>>> It's not
>>>     >>>>>>>> done in other parts of the help output that reference 
>>> options
>>>     >>>>>>>> by name. Also, no need to mention --exe since there is an
>>>     >>>>>>>> earlier comment in the help saying in must be used 
>>> together
>>>     >>>>>>>> with --core. This should help to simplify the help 
>>> message. I
>>>     >>>>>>>> would suggest:
>>>     >>>>>>>>
>>>     >>>>>>>>      --core, --pid, and --connect are mutually exclusive.
>>>     >>>>>>>>
>>>     >>>>>>>> There's also a typo in the version of the help that 
>>> does not
>>>     >>>>>>>> include --connect:
>>>     >>>>>>>>
>>>     >>>>>>>>    76 System.out.println(" <--core --exe> and <--pid> are
>>>     >>>>>>>> mutually eexclusive.");
>>>     >>>>>>>>
>>>     >>>>>>>> Notice "eexclusive".
>>>     >>>>>>>>
>>>     >>>>>>>> Otherwise it looks good.
>>>     >>>>>>>>
>>>     >>>>>>>> thanks,
>>>     >>>>>>>>
>>>     >>>>>>>> Chris
>>>     >>>>>>>>
>>>     >>>>>>>> On 7/8/19 5:06 AM, Yasumasa Suenaga wrote:
>>>     >>>>>>>>> Hi Chris,
>>>     >>>>>>>>>
>>>     >>>>>>>>> I uploaded new webrev:
>>>     >>>>>>>>>
>>>     >>>>>>>>> 
>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.06/
>>>     >>>>>>>>>
>>>     >>>>>>>>> It shows help messages as below:
>>>     >>>>>>>>>
>>>     >>>>>>>>> ```
>>>     >>>>>>>>> $ jhsdb jstack --help
>>>     >>>>>>>>> --locks                 To print java.util.concurrent 
>>> locks.
>>>     >>>>>>>>> --mixed                 To print both Java and native
>>>     >>>>>>>>> frames (mixed mode).
>>>     >>>>>>>>>     --pid <pid>             To attach to and operate 
>>> on the
>>>     >>>>>>>>> given live process.
>>>     >>>>>>>>>     --core <corefile>       To operate on the given 
>>> core file.
>>>     >>>>>>>>>     --exe <executable for corefile>
>>>     >>>>>>>>>     --connect [<id>@]<host> To connect to a remote debug
>>>     >>>>>>>>> server (debugd).
>>>     >>>>>>>>>
>>>     >>>>>>>>>     The --core and --exe options must be set together 
>>> to give
>>>     >>>>>>>>> the core
>>>     >>>>>>>>>     file, and associated executable, to operate on. 
>>> They can use
>>>     >>>>>>>>>     absolute or relative paths.
>>>     >>>>>>>>>     The --pid option can be set to operate on a live 
>>> process.
>>>     >>>>>>>>>     The --connect option can be set to connect to a debug
>>>     >>>>>>>>> server (debugd).
>>>     >>>>>>>>>     <--core --exe> and <--pid> and <--connect> are 
>>> mutually
>>>     >>>>>>>>> exclusive.
>>>     >>>>>>>>>
>>>     >>>>>>>>>     Examples: jhsdb jstack --pid 1234
>>>     >>>>>>>>>           or  jhsdb jstack --core ./core.1234 --exe 
>>> ./myexe
>>>     >>>>>>>>>           or  jhsdb jstack --connect debugserver
>>>     >>>>>>>>>           or  jhsdb jstack --connect id at debugserver
>>>     >>>>>>>>> ```
>>>     >>>>>>>>>
>>>     >>>>>>>>>
>>>     >>>>>>>>> Thanks,
>>>     >>>>>>>>>
>>>     >>>>>>>>> Yasumasa
>>>     >>>>>>>>>
>>>     >>>>>>>>>
>>>     >>>>>>>>> On 2019/07/08 16:14, Chris Plummer wrote:
>>>     >>>>>>>>>> Sorry, I meant "jhsdb debugd", not "clhsdb debugd".
>>>     >>>>>>>>>>
>>>     >>>>>>>>>> Chris
>>>     >>>>>>>>>>
>>>     >>>>>>>>>> On 7/8/19 12:09 AM, Chris Plummer wrote:
>>>     >>>>>>>>>>> Hi Yasumasa,
>>>     >>>>>>>>>>>
>>>     >>>>>>>>>>> I just noticed one more thing:
>>>     >>>>>>>>>>>
>>>     >>>>>>>>>>>   65 System.out.println(" --connect <[id@]host>
>>>     >>>>>>>>>>> To connect to a remote debug server (sadebugd).");
>>>     >>>>>>>>>>>
>>>     >>>>>>>>>>> Earlier on I incorrectly said that jstack and other 
>>> tools
>>>     >>>>>>>>>>> had a references to "sadebugd" in the help output. 
>>> It is
>>>     >>>>>>>>>>> actually "jsadebugd". But that was the name of the 
>>> command
>>>     >>>>>>>>>>> line tool, which is now gone. Instead now we have 
>>> "clhsdb
>>>     >>>>>>>>>>> debugd ...", so maybe it should just mention "debugd".
>>>     >>>>>>>>>>>
>>>     >>>>>>>>>>> thanks,
>>>     >>>>>>>>>>>
>>>     >>>>>>>>>>> Chris
>>>     >>>>>>>>>>>
>>>     >>>>>>>>>>> On 7/7/19 10:24 PM, Chris Plummer wrote:
>>>     >>>>>>>>>>>> Hi Yasumasa,
>>>     >>>>>>>>>>>>
>>>     >>>>>>>>>>>> I think it should be "[<id>@]<host>". Angle 
>>> brackets are
>>>     >>>>>>>>>>>> used to indicate non-literal values (ones to be 
>>> replaced by
>>>     >>>>>>>>>>>> something the user chooses), but the '@' is a literal
>>>     >>>>>>>>>>>> value, so should not be enclosed in the angle 
>>> brackets.
>>>     >>>>>>>>>>>>
>>>     >>>>>>>>>>>> Also one minor thing. You ended up duplicating the //:
>>>     >>>>>>>>>>>>
>>>     >>>>>>>>>>>>   60 // // --connect <[id@]host>
>>>     >>>>>>>>>>>>
>>>     >>>>>>>>>>>> thanks,
>>>     >>>>>>>>>>>>
>>>     >>>>>>>>>>>> Chris
>>>     >>>>>>>>>>>>
>>>     >>>>>>>>>>>> On 7/6/19 5:55 PM, Yasumasa Suenaga wrote:
>>>     >>>>>>>>>>>>> Hi Chris,
>>>     >>>>>>>>>>>>>
>>>     >>>>>>>>>>>>> Thank you for your advise.
>>>     >>>>>>>>>>>>> I uploaded new webrev. How about this?
>>>     >>>>>>>>>>>>>
>>>     >>>>>>>>>>>>> 
>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.04/
>>>     >>>>>>>>>>>>>
>>>     >>>>>>>>>>>>> I replaced "server" to "host" as you said.
>>>     >>>>>>>>>>>>> Other comments from you also have been fixed in it.
>>>     >>>>>>>>>>>>>
>>>     >>>>>>>>>>>>> For example, `jhsdb jstack --help` shows as below:
>>>     >>>>>>>>>>>>>
>>>     >>>>>>>>>>>>> ```
>>>     >>>>>>>>>>>>> $ jhsdb jstack --help
>>>     >>>>>>>>>>>>> --locks                 To print java.util.concurrent
>>>     >>>>>>>>>>>>> locks.
>>>     >>>>>>>>>>>>> --mixed                 To print both Java and native
>>>     >>>>>>>>>>>>> frames (mixed mode).
>>>     >>>>>>>>>>>>> --pid <pid>             To attach to and operate on
>>>     >>>>>>>>>>>>> the given live process.
>>>     >>>>>>>>>>>>> --core <corefile>       To operate on the given core
>>>     >>>>>>>>>>>>> file.
>>>     >>>>>>>>>>>>> --exe <executable for corefile>
>>>     >>>>>>>>>>>>> --connect <[id@]host>   To connect to a remote debug
>>>     >>>>>>>>>>>>> server (sadebugd).
>>>     >>>>>>>>>>>>>
>>>     >>>>>>>>>>>>> The --core and --exe options must be set together to
>>>     >>>>>>>>>>>>> give the core
>>>     >>>>>>>>>>>>> file, and associated executable, to operate on. They
>>>     >>>>>>>>>>>>> can use
>>>     >>>>>>>>>>>>> absolute or relative paths.
>>>     >>>>>>>>>>>>> The --pid option can be set to operate on a live 
>>> process.
>>>     >>>>>>>>>>>>> The --connect option can be set to connect to a debug
>>>     >>>>>>>>>>>>> server (sadebugd).
>>>     >>>>>>>>>>>>> <--core --exe> and <--pid> and <--connect> are 
>>> exclusive.
>>>     >>>>>>>>>>>>>
>>>     >>>>>>>>>>>>> Examples: jhsdb jstack --pid 1234
>>>     >>>>>>>>>>>>> or jhsdb jstack --core ./core.1234 --exe ./myexe
>>>     >>>>>>>>>>>>> or jhsdb jstack --connect debugserver
>>>     >>>>>>>>>>>>> or jhsdb jstack --connect id at debugserver
>>>     >>>>>>>>>>>>> ```
>>>     >>>>>>>>>>>>>
>>>     >>>>>>>>>>>>> If you are ok, I will reopen CSR (JDK-8224979).
>>>     >>>>>>>>>>>>>
>>>     >>>>>>>>>>>>>
>>>     >>>>>>>>>>>>> Yasumasa
>>>     >>>>>>>>>>>>>
>>>     >>>>>>>>>>>>>
>>>     >>>>>>>>>>>>> On 2019/07/06 6:26, Chris Plummer wrote:
>>>     >>>>>>>>>>>>>> On 7/4/19 3:53 PM, Yasumasa Suenaga wrote:
>>> >>>>>>>>>>>>>>> Hi Chris,
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> On 2019/07/05 4:24, Chris Plummer wrote:
>>> >>>>>>>>>>>>>>>> Hi Yasumasa,
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>> On 7/4/19 5:30 AM, Yasumasa Suenaga wrote:
>>> >>>>>>>>>>>>>>>>> Hi Chris,
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> Thank you for your review.
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> On 2019/07/04 8:07, Chris Plummer wrote:
>>> >>>>>>>>>>>>>>>>>> Hi Yasumasa,
>>> >>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>> Overall these changes look good, but I think 
>>> there is
>>> >>>>>>>>>>>>>>>>>> a bit of cleanup still needed.
>>> >>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>> You've changed the indentation of the help to always
>>> >>>>>>>>>>>>>>>>>> have a few spaces before the /t. If you are going to
>>> >>>>>>>>>>>>>>>>>> do this, then perhaps you don't need the /t anymore.
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> Ok, I will replace '\t' to whitespace.
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>> There are 3 checks for "remote != null". Shouldn't
>>> >>>>>>>>>>>>>>>>>> they be "remote != NO_REMOTE"?
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> I will fix them.
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>> The old jstack help output is a bit more informative
>>> >>>>>>>>>>>>>>>>>> than your output:
>>> >>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>      jstack [-m] [-l] [server_id@]<remote server IP
>>> >>>>>>>>>>>>>>>>>> or hostname>
>>> >>>>>>>>>>>>>>>>>>          (to connect to a remote debug server)
>>> >>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>> vs
>>> >>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>      --connect <[id@]server> To operate on the 
>>> remote
>>> >>>>>>>>>>>>>>>>>> debug server.
>>> >>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>> More specifically, you replaced <remote server IP or
>>> >>>>>>>>>>>>>>>>>> hostname> with "server". I think the former is a bit
>>> >>>>>>>>>>>>>>>>>> more self explanatory.
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> Exactly, but it is too long to show on the console.
>>> >>>>>>>>>>>>>>>>> So I used short word: server.
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> If we can ignore long line, or can add newline 
>>> (\n) on
>>> >>>>>>>>>>>>>>>>> help message,
>>> >>>>>>>>>>>>>>>>> I can change it. What do you think?
>>> >>>>>>>>>>>>>>>> I don't see why not. Isn't there already help output
>>> >>>>>>>>>>>>>>>> that relies on newlines?
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> As you can see on the CSR (JDK-8224979), format of 
>>> jhsdb
>>> >>>>>>>>>>>>>>> help messages is:
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> <option name> <blank (includes tab)> <description>
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> Thus I think long option / description is not 
>>> comfortable.
>>> >>>>>>>>>>>>>>> If we need to describe more, I think we should write it
>>> >>>>>>>>>>>>>>> as below:
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> --connect <[server-id@]remote server IP or hostname>
>>> >>>>>>>>>>>>>>>       To connect to a remote debug server.
>>>     >>>>>>>>>>>>>> Hi Yasumasa,
>>>     >>>>>>>>>>>>>>
>>>     >>>>>>>>>>>>>> We already have multiline examples like:
>>>     >>>>>>>>>>>>>>
>>>     >>>>>>>>>>>>>> |--pid <pid> To attach to and operate on the 
>>> given live
>>>     >>>>>>>>>>>>>> process.
>>>     >>>>>>>>>>>>>>
>>>     >>>>>>>>>>>>>> Is your concerned that the long option name will 
>>> extend
>>>     >>>>>>>>>>>>>> into the columns where the description normally 
>>> is? If
>>>     >>>>>>>>>>>>>> so, you can start the description on a new line 
>>> as you
>>>     >>>>>>>>>>>>>> suggest, or maybe come up with a different name 
>>> for the
>>>     >>>>>>>>>>>>>> option that isn't quite as long. My main 
>>> objection to
>>>     >>>>>>>>>>>>>> just saying "server" is it in no way conveys we are
>>>     >>>>>>>>>>>>>> talking about an IP host. Even just saying <host> 
>>> would
>>>     >>>>>>>>>>>>>> be better. It is also more correct since the host 
>>> isn't
>>>     >>>>>>>>>>>>>> necessarily what someone would consider to be a 
>>> server
>>>     >>>>>>>>>>>>>> (it could just be someone's desktop). <server-id> 
>>> on the
>>>     >>>>>>>>>>>>>> other hand is the correct term because we are 
>>> talking
>>>     >>>>>>>>>>>>>> about the id of the debug server running on a 
>>> particular
>>>     >>>>>>>>>>>>>> host.
>>>     >>>>>>>>>>>>>>
>>>     >>>>>>>>>>>>>> Chris
>>>     >>>>>>>>>>>>>> |
>>>     >>>>>>>>>>>>>>
>>>     >>>>>>>>>>>>
>>>     >>>>>>>>>>>>
>>>     >>>>>>>>>>>
>>>     >>>>>>>>>>>
>>>     >>>>>>>>>>
>>>     >>>>>>>>>>
>>>     >>>>>>>>
>>>     >>>>>>>>
>>>     >>>>>>
>>>     >>>>>>
>>>     >>>>
>>>     >>
>>>
>>
>



More information about the serviceability-dev mailing list