8253940: com/sun/jdi/JdwpAttachTest.java failed with "RuntimeException: ERROR: LingeredApp.startApp was able to attach" #2654

alexmenkov · 2021-02-19T20:10:14Z

Failures related to "no route to host" and "cannot bind to address" errors are covered by https://git.openjdk.java.net/jdk/pull/2633

This change fixes failures with listening on IPv6 loopback and attaching to "localhost" (the test connects to some other process which listens on the same port on IPv4 loopback and as a result gets "handshake failed - received >< - expected >JDWP-Handshake<" error)

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8253940: com/sun/jdi/JdwpAttachTest.java failed with "RuntimeException: ERROR: LingeredApp.startApp was able to attach"

Reviewers

Chris Plummer (@plummercj - Reviewer)
Leonid Mesnik (@lmesnik - Committer)

Download

$ git fetch https://git.openjdk.java.net/jdk pull/2654/head:pull/2654
$ git checkout pull/2654

bridgekeeper · 2021-02-19T20:11:04Z

👋 Welcome back amenkov! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2021-02-19T20:12:34Z

@alexmenkov The following label will be automatically applied to this pull request:

serviceability

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2021-02-19T20:15:47Z

Webrevs

01: Full - Incremental (2cf7031)
00: Full (fe12d32)

test/jdk/com/sun/jdi/JdwpAttachTest.java

plummercj · 2021-02-19T20:50:58Z

test/jdk/com/sun/jdi/JdwpAttachTest.java

+        return ipv6 == (addr instanceof Inet6Address);
+    }


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.

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?

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:

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 :)

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

Ok, that makes sense. Thanks

openjdk · 2021-02-20T03:06:33Z

@alexmenkov This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

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

Reviewed-by: cjplummer, lmesnik

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 146 new commits pushed to the master branch:

f304b74: 8261859: gc/g1/TestStringDeduplicationTableRehash.java failed with "RuntimeException: 'Rehash Count: 0' found in stdout"
f18c019: 8247373: ArraysSupport.newLength doc, test, and exception message
96c4321: 8262424: Change multiple get_java_xxx() functions in thread.cpp into one function
0de6abd: 8260966: (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView
5f4bc0a: 8253100: Fix "no comment" warnings in java.base/java.net
d185a6c: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now"
85a5ae8: 8261606: Surprising behavior of step over in String switch
be67aaa: 8262726: AArch64: C1 StubAssembler::call_RT can corrupt stack
0f6122b: 8262819: gc/shenandoah/compiler/TestLinkToNativeRBP.java fails with release VMs
dd33a8e: 8262461: handle wcstombsdmp return value correctly in unix awt_InputMethod.c
... and 136 more: https://git.openjdk.java.net/jdk/compare/9cf4f90d34fa17c8e9cbe2c4132ff5d7f3d692b7...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

alexmenkov · 2021-03-02T00:43:58Z

Ping. need 2nd reviewer.

alexmenkov · 2021-03-04T00:38:42Z

/integrate

openjdk · 2021-03-04T00:39:49Z

@alexmenkov Since your change was applied there have been 168 commits pushed to the master branch:

104a262: 8224775: test/jdk/com/sun/jdi/JdwpListenTest.java failed to attach
2848938: 8262927: Explicitly state fields examined for BigDecimal.hashCode
b397472: 8262915: java.awt.color.ColorSpace.getName() is not thread-safe
268d9b7: 8261447: MethodInvocationCounters frequently run into overflow
75aa154: 8259267: Refactor LoaderLeak shell test as java test.
a118185: 8261862: Expand discussion of rationale for BigDecimal equals/compareTo semantics
2d2ef08: 8262885: Shenandoah: FullGC prologue does not need to save/restore heap has_forwarded_object flag
1d2c1e6: 8248314: Parallel: Parallelize parallel full gc Adjust Roots phase
3d3eb5c: 8262368: wrong verifier message for bogus return type
6d3c858: 8259235: javac crashes while attributing super method invocation
... and 158 more: https://git.openjdk.java.net/jdk/compare/9cf4f90d34fa17c8e9cbe2c4132ff5d7f3d692b7...master

Your commit was automatically rebased without conflicts.

Pushed as commit d93fa0d.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

JDK-8253940

fe12d32

openjdk bot added the rfr Pull request is ready for review label Feb 19, 2021

openjdk bot added the serviceability serviceability-dev@openjdk.org label Feb 19, 2021

plummercj reviewed Feb 19, 2021

View reviewed changes

Updated per Chris feedback

2cf7031

plummercj approved these changes Feb 20, 2021

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Feb 20, 2021

lmesnik approved these changes Mar 2, 2021

View reviewed changes

openjdk bot closed this Mar 4, 2021

openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Mar 4, 2021

alexmenkov deleted the jdiAttachTest branch March 4, 2021 00:41

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

8253940: com/sun/jdi/JdwpAttachTest.java failed with "RuntimeException: ERROR: LingeredApp.startApp was able to attach" #2654

8253940: com/sun/jdi/JdwpAttachTest.java failed with "RuntimeException: ERROR: LingeredApp.startApp was able to attach" #2654

Uh oh!

alexmenkov commented Feb 19, 2021 •

edited by openjdk bot

Loading

Uh oh!

bridgekeeper bot commented Feb 19, 2021

Uh oh!

openjdk bot commented Feb 19, 2021

Uh oh!

mlbridge bot commented Feb 19, 2021 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

Uh oh!

plummercj Feb 19, 2021

Uh oh!

alexmenkov Feb 19, 2021

Uh oh!

plummercj Feb 20, 2021

Uh oh!

openjdk bot commented Feb 20, 2021 •

edited

Loading

Uh oh!

alexmenkov commented Mar 2, 2021

Uh oh!

alexmenkov commented Mar 4, 2021

Uh oh!

openjdk bot commented Mar 4, 2021

Uh oh!

Uh oh!

8253940: com/sun/jdi/JdwpAttachTest.java failed with "RuntimeException: ERROR: LingeredApp.startApp was able to attach" #2654

8253940: com/sun/jdi/JdwpAttachTest.java failed with "RuntimeException: ERROR: LingeredApp.startApp was able to attach" #2654

Uh oh!

Conversation

alexmenkov commented Feb 19, 2021 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Download

Uh oh!

bridgekeeper bot commented Feb 19, 2021

Uh oh!

openjdk bot commented Feb 19, 2021

Uh oh!

mlbridge bot commented Feb 19, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

Uh oh!

Uh oh!

Uh oh!

plummercj Feb 19, 2021

Choose a reason for hiding this comment

Uh oh!

alexmenkov Feb 19, 2021

Choose a reason for hiding this comment

Uh oh!

plummercj Feb 20, 2021

Choose a reason for hiding this comment

Uh oh!

openjdk bot commented Feb 20, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alexmenkov commented Mar 2, 2021

Uh oh!

alexmenkov commented Mar 4, 2021

Uh oh!

openjdk bot commented Mar 4, 2021

Uh oh!

Uh oh!

alexmenkov commented Feb 19, 2021 •

edited by openjdk bot

Loading

mlbridge bot commented Feb 19, 2021 •

edited

Loading

openjdk bot commented Feb 20, 2021 •

edited

Loading