RFR: JDK-8317920: JDWP-agent sends broken exception event with onthrow option [v6]

Chris Plummer cjplummer at openjdk.org
Wed Oct 18 20:06:48 UTC 2023


On Wed, 18 Oct 2023 07:07:45 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> test/jdk/com/sun/jdi/JdwpOnThrowTest.java line 121:
>> 
>>> 119:     private static String ATTACH_CONNECTOR = "com.sun.jdi.SocketAttach";
>>> 120:     // cache socket attaching connector
>>> 121:     private static AttachingConnector attachingConnector;
>> 
>> I would have expected a ListeningConnector to be used, so I'm a bit unsure how the attaching is working here and who is listening and who is initiating the connection. I don't understand some of these finer details of connectors and their args that well, but I would think that when using `onthrow` you would tell the debuggee what debugger port it should open the socket on, and the debugger would be listening on that port. Instead it seems you are telling the debuggee what port to listen on and the debugger is opening a socket on that port. Does that mean the open is done by the debugger before the debuggee even throws the exception, and that just leaves the debugger blocked on the open until the debuggee does an accept?
>
>> Does that mean the open is done by the debugger before the debuggee even throws the exception, and that just leaves the debugger blocked on the open until the debuggee does an accept?
> 
> Yes. This is for three reasons:
> 
> 1. server mode is the most commonly used mode
> 2. it is used by the `OnThrowTest` which is the other test that checks that the JDWP agent properly runs the `launch` command after the specified exception has been thrown
> 3. The original intent of onthrow is, is that the `launch` command launches the debugger (by running it in a new session via screen or tmux), this is why setting the `launch` option is mandatory when using the `onthrow` option. Nowadays most people use onthrow with an IDE, so we could think about removing the requirement.

Ok Thanks for the explanation. Maybe another thing that could be documented a bit better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16145#discussion_r1364474636


More information about the serviceability-dev mailing list