AIX JTReg Test Failure: java/net/Inet4Address/PingThis.java
Machines affected: test-ibm-ppc64-aix-71-1 and 2
JDK Versions: all
JVM: both
Platform: ppc64 aix
Passing run on build-osuosl-ppc64-aix-71-1: https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/2169/
Failing run: https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/2167/
10:17:53 STDOUT:
10:17:53 The target ip is 0.0.0.0
10:17:53 the target is reachable: false
10:17:53 Test failed
10:17:53 STDERR:
10:17:53 java.lang.Exception: address 0.0.0.0 can not be reachable!
10:17:53 at PingThis.main(PingThis.java:86)
10:17:53 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
10:17:53 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
10:17:53 at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
10:17:53 at java.base/java.lang.reflect.Method.invoke(Method.java:566)
10:17:53 at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
10:17:53 at java.base/java.lang.Thread.run(Thread.java:834)
@sej-jackson Are you able to work with @adam-thorpe to investigate this failing test case this week?
@sej-jackson @sxa
- Considering that both ibm systems have recently been rebuilt - can this be verified as still an issue - and stay open - or have we already seen enough testing the last week with the new builds to close is as 'no longer relevant'.
Need to run a Grinder to verify before closing, especially since this is quite an old issue
Is this a sanity/functional or what test (family)?
It's jtreg so will be part of the openjdk suite: https://github.com/adoptium/jdk8u/blob/master/jdk/test/java/net/Inet4Address/PingThis.java
Goiing to have to go back to school to understand where/how to enter jtreg as a test target/classification.
Don't need to invoke jtreg directly in Grinder - use jdk_custom as the target then put the full path to the java file in the field below.
See the instructions on replicating test failures in https://github.com/adoptium/infrastructure/blob/master/FAQ.md#how-do-i-replicate-a-test-failure
Result is different on test-osuosl-aix72-ppc64-2 - says test passed, but there is still STDERR message.
Checking on the ibm and build systems.
00:04:32.146 PingThis
00:04:32.146 STDOUT:
00:04:32.146 The target ip is 0.0.0.0
00:04:32.146 the target is reachable: true
00:04:32.146 Test passed
00:04:32.146 The target ip is 0:0:0:0:0:0:0:0
00:04:32.146 STDERR:
00:04:32.146 java.net.SocketException: A system call received a parameter that is not valid.
00:04:32.146 at java.net.Inet6AddressImpl.isReachable0(Native Method)
00:04:32.146 at java.net.Inet6AddressImpl.isReachable(Inet6AddressImpl.java:77)
00:04:32.146 at java.net.InetAddress.isReachable(InetAddress.java:503)
00:04:32.146 at java.net.InetAddress.isReachable(InetAddress.java:462)
00:04:32.146 at PingThis.main(PingThis.java:80)
00:04:32.146 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
00:04:32.146 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
00:04:32.147 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
00:04:32.147 at java.lang.reflect.Method.invoke(Method.java:498)
00:04:32.147 at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
00:04:32.147 at java.lang.Thread.run(Thread.java:748)
00:04:32.147
00:04:32.147 JavaTest Message: Test threw exception: java.net.SocketException
00:04:32.147 JavaTest Message: shutting down test
00:04:32.147
00:04:32.147
00:04:32.147 TEST RESULT: Failed. Execution failed: `main' threw exception: java.net.SocketException: A system call received a parameter that is not valid.
so, on ibm-test-aix71-ppc64-1, test still fails as the original post:
00:04:01.352 PingThis
00:04:01.352 STDOUT:
00:04:01.352 The target ip is 0.0.0.0
00:04:01.352 the target is reachable: false
00:04:01.352 Test failed
00:04:01.352 STDERR:
00:04:01.352 java.lang.Exception: address 0.0.0.0 can not be reachable!
00:04:01.352 at PingThis.main(PingThis.java:86)
00:04:01.352 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
00:04:01.352 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
00:04:01.352 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
00:04:01.352 at java.lang.reflect.Method.invoke(Method.java:498)
00:04:01.352 at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
00:04:01.352 at java.lang.Thread.run(Thread.java:748)
00:04:01.352
00:04:01.353 JavaTest Message: Test threw exception: java.lang.Exception
00:04:01.353 JavaTest Message: shutting down test
00:04:01.353
00:04:01.353
00:04:01.353 TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: address 0.0.0.0 can not be reachable!
WHILE on build-osuosl-aix71-ppc64-1 the test results are the same as with the aix72 system - test 'passes', but there is STDERR.
See https://ci.adoptopenjdk.net/job/Grinder/1549/, https://ci.adoptopenjdk.net/job/Grinder/1550/, and https://ci.adoptopenjdk.net/job/Grinder/1551/
As a last check, I also ran on test-osuosl-aix71-ppc64-1 and got the same result as on the other OSUOSL systems: test-PASS, with STDERR, so, unstable as final result:
00:05:01.595 PingThis
00:05:01.595 STDOUT:
00:05:01.595 The target ip is 0.0.0.0
00:05:01.595 the target is reachable: true
00:05:01.595 Test passed
00:05:01.595 The target ip is 0:0:0:0:0:0:0:0
00:05:01.595 STDERR:
00:05:01.595 java.net.SocketException: Invalid argument
00:05:01.595 at java.net.Inet6AddressImpl.isReachable0(Native Method)
00:05:01.595 at java.net.Inet6AddressImpl.isReachable(Inet6AddressImpl.java:77)
00:05:01.595 at java.net.InetAddress.isReachable(InetAddress.java:503)
00:05:01.595 at java.net.InetAddress.isReachable(InetAddress.java:462)
00:05:01.595 at PingThis.main(PingThis.java:80)
00:05:01.595 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
00:05:01.595 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
00:05:01.595 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
00:05:01.596 at java.lang.reflect.Method.invoke(Method.java:498)
00:05:01.596 at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
00:05:01.596 at java.lang.Thread.run(Thread.java:748)
00:05:01.596
00:05:01.596 JavaTest Message: Test threw exception: java.net.SocketException
00:05:01.596 JavaTest Message: shutting down test
00:05:01.596
00:05:01.596
00:05:01.596 TEST RESULT: Failed. Execution failed: `main' threw exception: java.net.SocketException: Invalid argument
...
[Pipeline] End of Pipeline
Finished: UNSTABLE
FYI:
- test-ibm-aix71-ppc64-1:
p159a01:/ # oslevel -s -q | head -4
Known Service Packs
-------------------
7100-05-06-2016
7100-05-06-2015
- build-osuosl-aix71-ppc64-2:
Known Service Packs
-------------------
7100-04-04-1717
7100-04-03-1642
- test-osuosl-aix71-ppc64-1
Known Service Packs
-------------------
7100-05-06-2028
7100-05-06-2016
Have to guess, but it seems there is a difference in configuration settings on the ibm hoisted systems.
OK - simplifying the issue:
PING 0.0.0.0: (0.0.0.0): 56 data bytes
--- 0.0.0.0 ping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss
compared with:
PING 0.0.0.0 (0.0.0.0): 56 data bytes
64 bytes from 140.211.9.1: icmp_seq=0 ttl=255 time=0 ms
64 bytes from 140.211.9.1: icmp_seq=1 ttl=255 time=0 ms
64 bytes from 140.211.9.1: icmp_seq=2 ttl=255 time=0 ms
OK. Gone about several tests on many AIX hosts - and
a) I am amazed that the OSUOSL systems respond at all on "0.0.0.0"
b) Looking on Linux (centos-7) I see that cli ping turns 0.0.0.0 into 127.0.0.1 and ::0 into ::1
c) AIX responds, according to documentation with 127.0.0.1 for both "InetAddress.getByName("") and InetAddress.getByName(null)
d) AIX responds with a error (command line) to "ping -a inet6 ::0"
ping -a inet6 ::0
ping: bind: Can't assign requested address
Willing to work on a change to the test, so it passes for AIX, by using different constants, but need a bit of help on what to clone - all of openjdk? or just the tests?
@aixtools Any change would need to be submitted to the upstream openjdk project if we can develop a fix - I wouldn't want to modify the code in our mirror of the respotories, however until we do that (It'll take a while to "round-trip" the test and a fix through openjdk) we should probably exclude the test on AIX for now if it's not easy to change the behavior via a change on the machine. (FYI @smlambert )
Basically, I was thinking: - since Windows is hard coded to return... that some special treatment for AIX might be considered.
public static void main(String args[]) throws Exception {
if (System.getProperty("os.name").startsWith("Windows")) {
return;
}
boolean isAIX = System.getProperty("os.name").startsWith("AIX");
boolean preferIPv4Stack = "true".equals(System
.getProperty("java.net.preferIPv4Stack"));
List<String> addrs = new ArrayList<String>();
InetAddress inetAddress = null;
addrs.add(""); // "0.0.0.0" is not compareable with null
if (!preferIPv4Stack) {
if (hasIPv6()) {
if (isAIX) {
addrs.add("::1");
} else {
addrs.add("::0");
}
}
}
for (String addr : addrs) {
inetAddress = InetAddress.getByName(addr);
System.out.println("The target ip is "
+ inetAddress.getHostAddress());
boolean isReachable = inetAddress.isReachable(3000);
System.out.println("the target is reachable: " + isReachable);
if (isReachable) {
System.out.println("Test passed ");
} else {
System.out.println("Test failed ");
throw new Exception("address " + inetAddress.getHostAddress()
+ " can not be reachable!");
}
}
}
}
- using "" rather than "0.0.0.0" as a 0 length string is closer to null
- for AIX, if IPv6 is active, provide "::1".
@aixtools Any change would need to be submitted to the upstream openjdk project if we can develop a fix - I wouldn't want to modify the code in our mirror of the respotories, however until we do that (It'll take a while to "round-trip" the test and a fix through openjdk) we should probably exclude the test on AIX for now if it's not easy to change the behavior via a change on the machine. (FYI @smlambert )
- So, short term - exclude the test (to resolve this), and I guess a new issue is needed
upstream.
- Was this test excluded? If so, please activate again.
- I'll submit a PR upstream asap.
- p.s. please add me as assignee
Looks to have been excluded at https://github.com/adoptium/aqa-tests/blame/master/openjdk/excludes/ProblemList_openjdk8.txt#L196 (and the equivalent line for OpenJ9 in https://github.com/adoptium/aqa-tests/blame/master/openjdk/excludes/ProblemList_openjdk8-openj9.txt)
We wouldn't want to re-enable that until we have verified that it passes (the point of us excluding is that we don't run things that won't work)
Suggest running a grinder with TARGET=jdk_custom and then filling in the CUSTOM_TARGET field (Not certin of the correct syntax in this case but it's possibly just java/net/Inet4Address/PingThis (If that doesn't work try with the .java extension)
I have submitted a PR upstream - https://github.com/openjdk/jdk/pull/7013 - but this will also need to be backported. I'll do that, but I have manually verified the changes on ibm-2 (which I'll switch back off now) - as well as on build-2.
Update: backports are not being accepted at https://github.com/openjdk/jdk8u.
It is testable via https://github.com/aixtools/jdk8u, branch PingThis_AIX
Update: backports are not being accepted at https://github.com/openjdk/jdk8u. It is testable via https://github.com/aixtools/jdk8u, branch PingThis_AIX
In that case we have two options (1) Hold a patch ourselves (Not ideal) (2) Leave it permanently excluded
I'd vote for the latter option in this case. FYI @smlambert
Update: backports are not being accepted at https://github.com/openjdk/jdk8u. It is testable via https://github.com/aixtools/jdk8u, branch PingThis_AIX
In that case we have two options (1) Hold a patch ourselves (Not ideal) (2) Leave it permanently excluded
I'd vote for the latter option in this case. FYI @smlambert
Well, it may take a while - but I would like to see it fixed upstream, and IF that happens, remove the exclusion again.
- aka - semi-permanent.
For now, I suggest we close this issue as resolved (semi-)-permanent exclusion. I'll open a new issue, should there ever be good news from upstream.
iirc: this has been fixed upstream - or is meant to be - as official 'skip on AIX' similar to Windows (also skipped).
Not sure if it is also being backported, but seems a good reason to simply add this to the 'skipped' tests file for adoptium testing on AIX. And then this could be closed.
has this been added to 'skipTests'? if yes, please close.
If not, does a new issue need to be opened (referencing this) to add this test to 'skipTests'?
closing. a) the machines indicated will soon be retired/reconfigured. b) afaik: the base code has been updated to skip this test (i.e., the test skips itself when the OS is AIX).