I've sent PR for this problem:
https://github.com/openjdk/jdk/pull/6941
`testResult` and `portInUse` are important variables in this logic,
however they are overwritten in lambda expression - they won't affect
to the caller.
(I wonder why the test can compile without any error...)
They are class member, so they work fine.
However it is a little confusing, so I refactored it in this PR.
Thanks,
Yasumasa
2021-12-31 18:49 に Yasumasa Suenaga さんは書きました:
Hi Matthias,
I think SADebugDTest.java wouldn't work that we expect.
```
114 Process debugd = startProcess("debugd", pb, null,
115 l -> {
116 if (!useRmiPort && l.contains(GOLDEN))
{
117 testResult = true;
118 } else if (useRmiPort &&
l.contains(RMI_CONNECTOR_IS_BOUND + finalRmiPort)) {
119 testResult = true;
120 } else if
(l.contains(ADDRESS_ALREADY_IN_USE)) {
121 portInUse = true;
122 }
123 return (l.contains(GOLDEN) ||
portInUse);
124 }, 20, TimeUnit.SECONDS);
```
`testResult` and `portInUse` are important variables in this logic,
however they are overwritten in lambda expression - they won't affect
to the caller.
(I wonder why the test can compile without any error...)
Anyway, we should fix it. I will fix and will send PR.
Thanks,
Yasumasa
On 2021/12/30 17:29, Baesken, Matthias wrote:
Hello, I have a question regarding the test SADebugDTest.java .
The test
https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/serviceability/sa/sadebugd/SADebugDTest.java
<https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/serviceability/sa/sadebugd/SADebugDTest.java>
seems to handle already cases where “Address already in use” is found
in the output (see line 120 ).
However in our nightly test, the SADebugDTest.java fails with this
output :
LingeredApp stdout: [];
LingeredApp stderr: []
LingeredApp exitValue = 0
----------System.err:(17/1318)----------
[debugd] Attaching to process ID 372 and starting RMI services, please
wait...
[debugd] Error attaching to process or starting server:
sun.jvm.hotspot.debugger.DebuggerException:
java.rmi.server.ExportException: Port already in use: 39399; nested
exception is:
*[debugd] java.net.BindException: Address already in use*
[debugd] at
jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:384)
java.lang.RuntimeException: Expected message "RMI connector is bound
to port 39399" is not found in the output.
at SADebugDTest.testWithPid(SADebugDTest.java:132)
at SADebugDTest.runTests(SADebugDTest.java:68)
at SADebugDTest.main(SADebugDTest.java:60)
at
java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base/java.lang.reflect.Method.invoke(Method.java:577)
at
com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
at java.base/java.lang.Thread.run(Thread.java:833)
JavaTest Message: Test threw exception: java.lang.RuntimeException:
Expected message "RMI connector is bound to port 39399" is not found
in the output.
JavaTest Message: shutting down test
Looks like the *ADDRESS_ALREADY_IN_USE *string is checked below;
however later in the coding portInUse is not checked but the
RuntimeException “Expected message . . .” is thrown :
Process debugd = startProcess("debugd", pb, null,
l -> {
if (!useRmiPort && l.contains(GOLDEN)) {
testResult = true;
} else if (useRmiPort &&
l.contains(RMI_CONNECTOR_IS_BOUND + finalRmiPort)) {
testResult = true;
* } else if
(l.contains(ADDRESS_ALREADY_IN_USE)) {*
* portInUse = true;*
}
return (l.contains(GOLDEN) || portInUse);
}, 20, TimeUnit.SECONDS);
// If we are here, this means we have received the
golden line and the test has passed
// The debugd remains running, we have to kill it
debugd.destroy();
debugd.waitFor();
* if (!testResult) {*
* throw new RuntimeException("Expected message \""
+*
* RMI_CONNECTOR_IS_BOUND + rmiPort + "\" is
not found in the output.");*
* }*
} while (portInUse); // Repeat the test if the port is
already in use
Is this really intended ? from the comments in the test I had the
impression that in case of “port in use” / “address already in
use” the test should be repeated ?
Otherwise if this is intended, should we flag the test with @key
intermittent ?
Thanks and best regards, Matthias
