JDK-8199931 : java/net/MulticastSocket/UnreferencedMulticastSockets.java fails with "incorrect data received"
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 11
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2018-03-21
  • Updated: 2021-08-27
  • Resolved: 2018-09-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 12
11.0.13-oracleFixed 12 b13Fixed
Related Reports
Relates :  
JDK-8195059 - Update java.net Socket and DatagramSocket implementations to use Cleaner
Description
Observed once on Oracle Linux 7 x64 with jdk 11 b04 repeated runs.  

Output as below:
  DatagramServer addr: localhost/127.0.0.1: 45381
  serverMulticastSocket:: fd: java.io.FileDescriptor@447be3e9, fd: 7, cleanup: java.net.SocketCleanable@bac6c4
socketImplClass: class java.net.PlainDatagramSocketImpl
socketImpl class name not matched: java.net.PlainDatagramSocketImpl != java.net.TwoStacksPlainDatagramSocketImpl
  clientMulticastSocket:: fd: java.io.FileDescriptor@153b9167, fd: 8, cleanup: java.net.SocketCleanable@999d25c
socketImplClass: class java.net.PlainDatagramSocketImpl
socketImpl class name not matched: java.net.PlainDatagramSocketImpl != java.net.TwoStacksPlainDatagramSocketImpl
echo received from: /127.0.0.1:45381
----------System.err:(13/908)----------
java.lang.AssertionError: incorrect data received: expected: 2, actual: 1
	at UnreferencedMulticastSockets.main(UnreferencedMulticastSockets.java:137)
	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:564)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115)
	at java.base/java.lang.Thread.run(Thread.java:842)
Comments
Fix request (11u): Clean test backport for Oracle 11.0.13 parity. No risk, test still works.
25-08-2021
Above pushed change is just to print client bound port to confirm the suspicion in the beginning (whether client reused same address with server), you may find some details about this change in the RFR mail threads. If we see next same failure sample with the log "DatagramServer addr: localhost/127.0.0.1: xxx" and "client bound port: xxx" printed same port, it should prove the guess, then we may use RFR first proposed change to address it.
21-09-2018
URL: http://hg.openjdk.java.net/jdk/jdk/rev/d2c72de3cf83 User: amlu Date: 2018-09-21 07:59:51 +0000
21-09-2018
RFR: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055593.html
20-09-2018
Though I cannot prove this bug reported failure caused by same condition as above since failure samples too less, and I even cannot explain what's scenario will cause multiple "new MulticastSocket(0)" call bind to same port (maybe when os port resource been heavily consumed? or due to os port random policy?). But guess we could still add some logic to try to prevent such things.
19-09-2018
Not found other similar failure on mach5, so guess above one is the only sample what we have. The info is limited, so most of below analysis are based on guess, correct me if anything I misunderstand. From log and exception, it looks like client socket received the message which sent by itself, look into MulticastSocket source code, in constructor, it set reuse address true, that means we may have multiple MulticastSocket binding same address. public MulticastSocket(SocketAddress bindaddr) throws IOException { super((SocketAddress) null); // Enable SO_REUSEADDR before binding setReuseAddress(true); Follow above idea, I modified the original test to bind same port for each "new MulticastSocket(port)", that will create a scenario that both client and server socket are using same port, the run behaviors looks different on different platform, but on OEL7 x64 (same with this bug report platform), I got the same failure message and exception, so the bug got reproed under this very specified condition
19-09-2018
Did it possible received message by itself? Since it is using loopback address.
21-03-2018