RFR: 8253940: com/sun/jdi/JdwpAttachTest.java failed with "RuntimeException: ERROR: LingeredApp.startApp was able to attach" [v2]

[Alex Menkov]

On Fri, 19 Feb 2021 20:50:58 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> In the CR you said:
> 
> > But JDI framework respects "java.net.preferIPv6Addresses" system property (which by default is false), so connecting to empty host tries IPv4 addresses 1st and tries IPv6 addresses only if connect to IPv4 failed.
> 
> Are you referring to the JDI implementation, or the JDI test framework. In any case, I had trouble locating this anywhere in the source.

This is about JDI implementation (the test uses JDWP agent to attach - corresponding code is at src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c)

> Also, "preferv6" doesn't mean that's what it ends up using. It just tries v6 first before deferring to v4 if v6 fails (or the opposite if it doesn't prefer v6). I don't think you are capturing that part of the logic. What happens if preferv6 is true but the connect to a v6 port fails. Should the test try to connect to the v4 in that case?

Well. Lets consider the case when we have both IPv4 and IPv6 loopback addresses and "preferv6" is true (for "preferv6" == false it works opposite).
The test does:
1. - listen on IPv6 loopback ("::1")
   - tries to attach to localhost
     JDI 1st tries IPv6, which is expected to succeed. If it fails, that means the test should fail too. Theoretically in the case test can successfully attach to some other process which listens on the same port IPv4 loopback, but we expect the test to pass :)
2. - listen on IPv4 loopback (127.0.0.1)
   - tries to attach to localhost.
      JDI 1st tries IPv6, which is expected to fail, but if there is some other process which listens on the same port on IPv6 loopback, we get the error like described in the issue (handshake failure)

So the logic is to test 1 and skip 2

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

PR: https://git.openjdk.java.net/jdk/pull/2654