JDK-7143960 : java/net/DatagramSocket/SendDatagramToBadAddress.java is failing on Mac OS X
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 7u4,8,9
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: os_x
  • CPU: x86
  • Submitted: 2012-02-08
  • Updated: 2020-11-25
  • Resolved: 2020-05-18
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 15
15Resolved
Related Reports
Duplicate :  
JDK-8241072 - Reimplement the Legacy DatagramSocket API
Relates :  
JDK-8230211 - Prepare DatagramSocket for alternative DatagramSocketImpl
Relates :  
JDK-7144268 - [macosx] ProblemList.txt updates to exclude networking tests failing on Mac OS X
Relates :  
JDK-7164518 - No PortUnreachableException when connecting to a non-existing DatagramSocket (mac)
Description
This test is failing because calling receive followed by a send on a datagram socket connected to a port on which no process is listening does not cause an ICMP Unreacheble Port Exception (ECONNREFUSED) to be thrown on Mac OS X. This test was originally modified as a part of CR 7123679 to reflect that this Exception will be thrown on Mac OS X.
Comments
Reclosing as a duplicate of JDK-8241072.
18-05-2020
Only bugs associated with changesets should be closed as "fixed".
18-05-2020
Fixed as part of JDK-8241072
18-05-2020
an FYI note on this ... the PortUnreachableException only occurs when the sending DatagramSocket is connected. If it is not connected the OS kernel doesn't convey it to the application. Additionally, the exception doesn't occur for the immediate send that will cause the ICMP port unreachable message, it will happen on the next send/receive method invocation on the sending DatagramSocket - connected send and non connected send result in different call flows which are eventually to send and sendto syscalls respectively. So scenario, on macOS, for PUE to occur is create sender DatagramSocket connect to recipient per address and port send datagram then the next invocation send or receive will see a PUE being thrown, as per extracted call flow below SERVER SOCKET CLOSED sending 6 packets to connected closed server send packet 0 to non existent server DatagramSocketAdapter::send - ENTER address null:0 DatagramSocketAdapter::send - packet address is null DatagramSocketAdapter::send - check for connected address DatagramChannelImpl::send - connected IOUtil.write IOUtil::write - ENTER IOUtil::write - DirectBuffer IOUtil::writeFromNativeBuffer - ENTER IOUtil::writeFromNativeBuffer - nd is a sun.nio.ch.DatagramDispatcher IOUtil::writeFromNativeBuffer - nd.write Java_sun_nio_ch_DatagramDispatcher_write0: result == 14 Java_sun_nio_ch_DatagramDispatcher_write0: errno == 35 send packet 1 to non existent server DatagramSocketAdapter::send - ENTER address null:0 DatagramSocketAdapter::send - packet address is null DatagramSocketAdapter::send - check for connected address DatagramChannelImpl::send - connected IOUtil.write IOUtil::write - ENTER IOUtil::write - DirectBuffer IOUtil::writeFromNativeBuffer - ENTER IOUtil::writeFromNativeBuffer - nd is a sun.nio.ch.DatagramDispatcher IOUtil::writeFromNativeBuffer - nd.write Java_sun_nio_ch_DatagramDispatcher_write0: result == -1 Java_sun_nio_ch_DatagramDispatcher_write0: errno == 61 Got expected exception: java.net.PortUnreachableException so note that on each second alternative OS send in the sequence results in a -1 and returns with an error 61 (ECONNREFUSED) even thought the previous send actually takes place, as per tcpdump below. 14:20:28.284314 IP localhost.53230 > localhost.53231: UDP, length 14 14:20:28.285020 IP localhost.53230 > localhost.53231: UDP, length 14 14:20:28.285431 IP localhost.53230 > localhost.53231: UDP, length 14 14:20:28.285918 IP localhost.53230 > localhost.53231: UDP, length 14 14:20:28.286256 IP localhost.53230 > localhost.53231: UDP, length 14 14:20:28.286617 IP localhost.53230 > localhost.53231: UDP, length 14 14:20:28.297574 IP localhost.53230 > localhost.53231: UDP, length 14 **** server socket closed ******* 14:20:28.299711 IP localhost.53230 > localhost.53231: UDP, length 14 14:20:28.299744 IP localhost > localhost: ICMP localhost udp port 53231 unreachable, length 36 14:20:28.300406 IP localhost.53230 > localhost.53231: UDP, length 14 14:20:28.300424 IP localhost > localhost: ICMP localhost udp port 53231 unreachable, length 36 14:20:28.301028 IP localhost.53230 > localhost.53231: UDP, length 14 14:20:28.301049 IP localhost > localhost: ICMP localhost udp port 53231 unreachable, length 36 It is the unsolicited and asynchronous nature of the ICMP message flow that leads to the disassociation between the Exception and the send. as such, in a sequence of six packet sends, it will result in three PUE. The original test includes a receive method call paired with each send in order to trigger the six PUE. Again note that this will only occur on connected DatagramSockets as seen in the tcpdump shows 6 ICMP messages resulting from six sends 14:17:19.115769 IP localhost.53228 > localhost.53229: UDP, length 14 14:17:19.117535 IP localhost.53228 > localhost.53229: UDP, length 14 14:17:19.119254 IP localhost.53228 > localhost.53229: UDP, length 14 14:17:19.120566 IP localhost.53228 > localhost.53229: UDP, length 14 14:17:19.121708 IP localhost.53228 > localhost.53229: UDP, length 14 14:17:19.122716 IP localhost.53228 > localhost.53229: UDP, length 14 14:17:19.128355 IP localhost.53228 > localhost.53229: UDP, length 14 14:17:19.130577 IP localhost.53228 > localhost.53229: UDP, length 14 14:17:19.130606 IP localhost > localhost: ICMP localhost udp port 53229 unreachable, length 36 14:17:19.131301 IP localhost.53228 > localhost.53229: UDP, length 14 14:17:19.131324 IP localhost > localhost: ICMP localhost udp port 53229 unreachable, length 36 14:17:19.131776 IP localhost.53228 > localhost.53229: UDP, length 14 14:17:19.131798 IP localhost > localhost: ICMP localhost udp port 53229 unreachable, length 36 14:17:19.132257 IP localhost.53228 > localhost.53229: UDP, length 14 14:17:19.132278 IP localhost > localhost: ICMP localhost udp port 53229 unreachable, length 36 14:17:19.132835 IP localhost.53228 > localhost.53229: UDP, length 14 14:17:19.132861 IP localhost > localhost: ICMP localhost udp port 53229 unreachable, length 36 14:17:19.133566 IP localhost.53228 > localhost.53229: UDP, length 14 14:17:19.133594 IP localhost > localhost: ICMP localhost udp port 53229 unreachable, length 36 As such, an application in a send loop, where the server has dies will see some of its send invocations appear to succeed and others receive the PUE, possibly leading to some level of confusion
16-04-2020
This seems to work fine against the sandbox jep373 build :+1 reveive DatagramPacket receive: ENTER Expecting 10 packets Received expected packet Received expected packet Received expected packet Received expected packet Received expected packet Received expected packet Received expected packet Received expected packet Received expected packet Received expected packet Checking send to non-connected address ... receive: ENTER Expecting 1 packets Received expected packet Checking send to closed server ... SERVER SOCKET CLOSED sending 10 packets to connected closed server send packet 0 to non existent server receive packet 0 from nonbody Got expected exception: java.net.PortUnreachableException send packet 1 to non existent server receive packet 1 from nonbody Got expected exception: java.net.PortUnreachableException send packet 2 to non existent server receive packet 2 from nonbody Got expected exception: java.net.PortUnreachableException send packet 3 to non existent server receive packet 3 from nonbody Got expected exception: java.net.PortUnreachableException
15-04-2020
I used a recent build of master /Users/owner/MARK_SHEPPARD/jdk_jdk_master/build/macosx-x64/images/jdk/bin/java -version java version "15-internal" 2020-09-15 Java(TM) SE Runtime Environment (build 15-internal+0-2020-04-14-1856013.owner...) Java HotSpot(TM) 64-Bit Server VM (build 15-internal+0-2020-04-14-1856013.owner..., mixed mode, sharing)
15-04-2020
This test is in the problem list. It would be interesting to check if it's been fixed by JEP 373 implementation in the JDK-8230211-branch $ grep 7143960 test/jdk/ProblemList.txt java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 macosx-all
15-04-2020
modified the test slightly removed the datagramsocker::receive in the second part of the test after the server socket (i.e. recipient) has been closed. Also increased the number of sends. Executed a tcpdump to monitor lo0 (127.0.0.1) and we see the icmp packets being sent back for the port not reachable. So it is on the receiving side that the event is not being relayed to the sending DatagramSocket -- expectation is that next operation on the socket will receive the error .... in this instance the receive invocation. the tcpdump shows the ICMP message being sent indicating the port is unreachable 00:39:28.735778 IP localhost.58759 > localhost.58760: UDP, length 14 00:39:28.736166 IP localhost.58759 > localhost.58760: UDP, length 14 00:39:28.736354 IP localhost.58759 > localhost.58760: UDP, length 14 00:39:28.736606 IP localhost.58759 > localhost.58760: UDP, length 14 00:39:28.736802 IP localhost.58759 > localhost.58760: UDP, length 14 00:39:28.737068 IP localhost.58759 > localhost.58760: UDP, length 14 00:39:28.737267 IP localhost.58759 > localhost.58760: UDP, length 14 00:39:28.737544 IP localhost.58759 > localhost.58760: UDP, length 14 00:39:28.737715 IP localhost.58759 > localhost.58760: UDP, length 14 00:39:28.737930 IP localhost.58759 > localhost.58760: UDP, length 14 00:39:28.739168 IP localhost.58759 > localhost.58760: UDP, length 14 00:39:28.739933 IP localhost.58759 > localhost.58760: UDP, length 14 00:39:28.739958 IP localhost > localhost: ICMP localhost udp port 58760 unreachable, length 36 00:39:28.740066 IP localhost.58759 > localhost.58760: UDP, length 14 00:39:28.740078 IP localhost > localhost: ICMP localhost udp port 58760 unreachable, length 36 00:39:28.740190 IP localhost.58759 > localhost.58760: UDP, length 14 00:39:28.740207 IP localhost > localhost: ICMP localhost udp port 58760 unreachable, length 36 00:39:28.740295 IP localhost.58759 > localhost.58760: UDP, length 14 00:39:28.740310 IP localhost > localhost: ICMP localhost udp port 58760 unreachable, length 36 00:39:28.740395 IP localhost.58759 > localhost.58760: UDP, length 14 00:39:28.740405 IP localhost > localhost: ICMP localhost udp port 58760 unreachable, length 36 00:39:28.740488 IP localhost.58759 > localhost.58760: UDP, length 14 00:39:28.740502 IP localhost > localhost: ICMP localhost udp port 58760 unreachable, length 36 00:39:28.740621 IP localhost.58759 > localhost.58760: UDP, length 14 00:39:28.740634 IP localhost > localhost: ICMP localhost udp port 58760 unreachable, length 36 00:39:28.740819 IP localhost.58759 > localhost.58760: UDP, length 14 00:39:28.740832 IP localhost > localhost: ICMP localhost udp port 58760 unreachable, length 36 00:39:28.741024 IP localhost.58759 > localhost.58760: UDP, length 14 00:39:28.741039 IP localhost > localhost: ICMP localhost udp port 58760 unreachable, length 36 00:39:28.741227 IP localhost.58759 > localhost.58760: UDP, length 14 00:39:28.741243 IP localhost > localhost: ICMP localhost udp port 58760 unreachable, length 36 we also note that connect on macOS is (still) not being called at the OS level - some documentation allude to this being a pre-requisite for receiving ICMP not reachable error ... elsewhere it is said that the ICMP errors are masked for UDP sockets and it requires a raw IP socket to receive them. Alternatively the connect emulation code performs a peek on the socket, this in turn call NET_Timeout, which calls select, but with only with a read fd set, the error or exception condition set is null. It is possible that when performing a select that the ICMP message with port unreachable message is received asynchronously and hence needs to be received within a select via the errorfds set parameter. As such it gets discarded in the peek operation.
15-04-2020
7164518 is related to this. The mac implementation is emulated in Java. It is possible to enable it natively and get the required behaviour, but this introduces some side effects. It is an OS issue, and something that could be raised with Apple. Agree that it worthwhile modifying the test as suggested.
21-11-2013
Specification of DatagramSocket.receive() states that "PortUnreachableException - may be thrown if the socket is connected to a currently unreachable destination. Note, there is no guarantee that the exception will be thrown." Therefore the observed failure to throw the expected PortUnreachableException is not really an error. Given that the underlying Mac implementation does not support the behavior, it sees that in SendDatagramToBadAddress the OSsupportsFeature() method should return 'false' for Mac OS X. This would allow the test to be removed from ProblemList.txt. If the feature should be supported perhaps another issue should be filed to track the problem?
20-11-2013
This one is not critical for 8, and probably will go away anyway once the DatagramSocket implementation has been re-vamped to use the kernel support for connected datagrams.
13-09-2013
EVALUATION This test is failing because DatagramSocket.connect() is now only being emulated on Mac OS X.
14-02-2012