JDK-7084030 : DatagramSocket.getLocalAddress inconsistent on XP/2003 when IPv6 enabled and socket is connected
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 8
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-08-27
  • Updated: 2013-09-06
  • Resolved: 2011-10-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 8
8 b10Fixed
Related Reports
Duplicate :  
JDK-7141822 - java/nio/channels/DatagramChannel/ChangingAddress.java failing on OS X
Relates :  
JDK-7098037 - java/net/DatagramSocket/ChangingAddress.java fail on Windows Vista and Windows 2008
Description
If IPv6 is enabled on Windows XP or Windows Server 2003 then this test fails. This may actually be an oddity in java.net.DatagramSocket but should be investigated so that the test runs reliably in the nightly testing where some machines have the experimental IPv6 stack enabled.


#Test Results (version 2)
#Sat Aug 27 07:18:37 BST 2011
#checksum:66eb750160cc903f
#-----testdescription-----
$file=D:\\alan\\test\\java\\nio\\channels\\DatagramChannel\\ChangingAddress.java
$root=D:\\alan\\test
keywords=bug6431343
run=ASSUMED_ACTION main ChangingAddress\r\n
source=ChangingAddress.java
title=Test that DatagramChannel.getLocalAddress returns the right local address after connect/disconnect.

#-----environment-----

#-----testresult-----
description=file:/D:/alan/test/java/nio/channels/DatagramChannel/ChangingAddress.java
elapsed=47 0:00:00.047
end=Sat Aug 27 07:18:37 BST 2011
environment=regtest
execStatus=Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Expected: 0.0.0.0/0.0.0.0, actual: /10.169.79.120
hostname=MRCOOL
javatestOS=Windows 2003 5.2 (amd64)
javatestVersion=4.1.4
script=com.sun.javatest.regtest.RegressionScript 
sections=script_messages build compile main
start=Sat Aug 27 07:18:37 BST 2011
test=java/nio/channels/DatagramChannel/ChangingAddress.java
work=D:\\alan\\JTwork\\java\\nio\\channels\\DatagramChannel

#section:script_messages
----------messages:(4/216)*----------
JDK under test: (D:\\alan\\jdk1.8)
java version "1.8.0-internal"
Java(TM) SE Runtime Environment (build 1.8.0-internal-201108252105.ab23780.jdk-b00)
Java HotSpot(TM) 64-Bit Server VM (build 22.0-b01, mixed mode)

#section:build
----------messages:(3/103)----------
command: build ChangingAddress
reason: Named class compiled on demand
elapsed time (seconds): 0.031
result: Passed. Build successful

#section:compile
----------messages:(3/175)*----------
command: compile D:\\alan\\test\\java\\nio\\channels\\DatagramChannel\\ChangingAddress.java
reason: .class file out of date or does not exist
elapsed time (seconds): 0.031
result: Passed. Compilation successful

#section:main
----------messages:(3/132)----------
command: main ChangingAddress
reason: Assumed action based on file name: run main ChangingAddress 
elapsed time (seconds): 0.016
----------System.err:(13/709)----------
java.lang.RuntimeException: Expected: 0.0.0.0/0.0.0.0, actual: /10.169.79.120
	at ChangingAddress.check(ChangingAddress.java:43)
	at ChangingAddress.main(ChangingAddress.java:61)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:474)
	at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:680)
	at java.lang.Thread.run(Thread.java:722)

JavaTest Message: Test threw exception: java.lang.RuntimeException
JavaTest Message: shutting down test

result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Expected: 0.0.0.0/0.0.0.0, actual: /10.169.79.120


test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Expected: 0.0.0.0/0.0.0.0, actual: /10.169.79.120
Comments
Test passed on win xp/2003 machines but failed on MacOSX, Verify this issue and link it to JDK-7141822.
06-09-2013
EVALUATION http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7f1aca641910
27-09-2011
EVALUATION Chris - Maybe it would make sense to simply moved the handling of SO_BINDADDR to a new, two stacks only, native method like how it is done in DualStackPlainDatagramSocketImpl.getOption. That is, add a method like socketLocalAddress to two stacks. If you do this the native two stacks socketGetOption will be much simpler and the new two stacks native socketLocalAddress will contain the specific code to retrieve the local address. And no Solaris of dual stack code needs to change.
23-09-2011
EVALUATION The inconsistency arises because fd and fd1 are not set correctly after connecting a DatagramSocket to a remote local address in src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c:connect0(). As a result of this, src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java:getOption returns anyLocalBoundAddr when DatagramSocket.getLocalAddress() is called. fd1 is meant to be null after DatagramSocket is connected to a remote address,and fd is meant to point to the correct file descriptor (for both ipv4 and ipv6 addresses). However, this may give rise to another problem: if we connect to an IPv4 address, disconnect and then try to connect to an IPv6 address: the code will throw an undesired exception. The goal of fixing this bug now is to ensure that the test doesn't fail and the code for DatagramSocket.getLocalAddress() behaves correctly in corner-cases as stated above.
08-09-2011