JDK-8281545 : java/net/ipv6tests/UdpTest.java fails with java.lang.Exception: packets not the same
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 11
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: os_x
  • CPU: x86
  • Submitted: 2022-02-09
  • Updated: 2024-05-21
Related Reports
Relates :  
JDK-8198266 - java/net/ipv6tests/UdpTest.java fails with timeout
Description
This is a one off failure observed on JDK 11 CI

----------System.err:(15/803)----------
java.lang.Exception: packets not the same
	at Tests.comparePackets(Tests.java:148)
	at Tests.simpleDataExchange(Tests.java:101)
	at UdpTest.test1(UdpTest.java:93)
	at UdpTest.main(UdpTest.java:80)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
	at java.base/java.lang.Thread.run(Thread.java:834)

This test could benefit from additional logging info - in particular - what was in the packets that did not match, and what addresses where used on both sides. Possibly the test should be hardened to reject packets that were not emitted by the test itself. Also the test should use try-with-resource to ensure that sockets are properly closed, and should preferably be run in /othervm to avoid potential limitation on datagram sockets in the agent VM.

Note that JDK 11 still has the old DatagramSocket implementation. I haven't observed this particular failure on the latest JDK yet. 
This is a different failure than those observed in JDK-8198266
Comments
Cleaning up older issues, not currently working on this so un-marking it as "In Progress"
09-11-2023
The current version of test in JDK18 or mainline uses the debug option to provide some diagnostics i.e. address and port usage in the test. current jdk18 also has an additional ia4addr check to ensure that IPv4 addresses are available. Additionally, the test could be run othervm to avoid any possible interference from samevm mode, and this will also ensure diagnostic output if the test gets "stuck" in a receive and times out. This failure is first test test1 ... two DatagramSocket bound to wildcard and ephemeral port send and receive to first available IPv4 address ... a printing of the received mismatched datagrams would be helpful (in open/test/jdk/java/net/ipv6tests/Tests.java) For another process to interfere with this test, then the same ephemeral port (or ports) would have to be allocated to a DatagramSocket in the other process and the socket binding for the this test's DatagramSocket would need to have SO_REUSEADDR option set to avoid BindException. We have observed the allocation of an ephemeral port twice by the OS under heavy network usage, where large volumes of ports have been allocated with intermittent in java/net/Socket/UdpSocket.java BUT that was failing with an unexpected BindException due to the double ephemeral port allocation c.f. https://bugs.openjdk.java.net/browse/JDK-8265362 For this failure scenario the netstat -av output was not captured and there is 4/5 other concurrent network tests executing (a couple of multicast socket ones) so reasonable network activity but none that should interfere with this test !! currently in the main line (and JDK18) a likely failure for this test on macOS is the not receipt of a datagram -- intermittently datagrams in UDP based tests are being dropped
16-02-2022