JDK-8065078 : NetworkInterface.getNetworkInterfaces() triggers intermittent test failures
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: generic
  • Submitted: 2014-11-17
  • Updated: 2021-10-15
  • Resolved: 2015-03-09
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 6 JDK 7 JDK 8 JDK 9
6u181Fixed 7u171Fixed 8u102Fixed 9 b55Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
 ThreadLocalRandom initialization causes sun/net/www/protocol/http/B6369510.java failed intermittently. This due to the initial seed creation using NetworkIntereface.getNetworkInterfaces() for its random number creation. The NetworkIntereface.getNetworkInterfaces() call flow can fail intermittently
due to GetAdaptersAddresses failing. Further discussion details below.

  This happened once in JDK9/b38 same binaries runs on Windows. It is probably related with teredo pseudo interface, which may change timely.

The error is like:
----------System.err:(31/2081)----------
java.lang.Error: IP Helper Library GetAdaptersAddresses function failed
	at java.net.NetworkInterface.getAll(Native Method)
	at java.net.NetworkInterface.getNetworkInterfaces(NetworkInterface.java:343)
	at java.util.concurrent.ThreadLocalRandom.initialSeed(ThreadLocalRandom.java:153)
	at java.util.concurrent.ThreadLocalRandom.<clinit>(ThreadLocalRandom.java:137)
	at java.util.concurrent.ConcurrentSkipListMap.doPut(ConcurrentSkipListMap.java:857)
	at java.util.concurrent.ConcurrentSkipListMap.putIfAbsent(ConcurrentSkipListMap.java:1962)
	at java.util.concurrent.ConcurrentSkipListSet.add(ConcurrentSkipListSet.java:241)
	at java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:816)
	at java.net.InetAddress.getAllByName0(InetAddress.java:1249)
	at java.net.InetAddress.getAllByName0(InetAddress.java:1169)
	at java.net.InetAddress.getHostFromNameService(InetAddress.java:615)
	at java.net.InetAddress.getHostName(InetAddress.java:540)
	at java.net.InetAddress.getHostName(InetAddress.java:512)
	at java.net.InetSocketAddress$InetSocketAddressHolder.getHostName(InetSocketAddress.java:82)
	at java.net.InetSocketAddress$InetSocketAddressHolder.access$600(InetSocketAddress.java:56)
	at java.net.InetSocketAddress.getHostName(InetSocketAddress.java:345)
	at B6369510.doClient(B6369510.java:63)
	at B6369510.<init>(B6369510.java:52)
	at B6369510.main(B6369510.java:45)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
	at java.lang.Thread.run(Thread.java:745)
Comments
URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c3b558249c32 User: lana Date: 2015-03-18 00:54:38 +0000
18-03-2015

URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c3b558249c32 User: msheppar Date: 2015-03-09 18:46:45 +0000
09-03-2015

the error code 111 is ERROR_BUFFER_OVERFLOW this is handled at certain points in the call flow. Thus, based on the call logic it would appear that the realloc is also failing to allocate sufficient memory for the memory addresses in the second or subsequent GetAdaptersAddresses function call. Rather than attempting, another realloc and retry of GetAdaptersAddresses call block a simpler remedy might be to increase the bufsize from 1024 to 2048
25-02-2015

Raise to P3, since it affects so many test cases and a bit of frequently.
05-01-2015

This bug appears to run into an issue when trying to retrieve the network interfaces from the machine. The test itself does not directly try to retrieve this information, it is a side-effect of the initialization of ThreadLocalRandom, where it is being used as a source of entropy for an initial seed . There is another bug, JDK-8060435, that is attempting to remove the networking code from the initialization of TLR. The title of this bug may need to be updated so make this clear.
26-11-2014

I've run this test standalone and it throws an exception. The HttpServer is created with a wildcard address, and this is retrieved in the call to address.getHostName(). This forms part of the URL string passed to the URL constructor, which the URL constructor doesn't like!!. If the test is run under jtreg it will nominally pass, but view the test log will show the exception. So we need to rectify the test, also. Will create a separate bug https://bugs.openjdk.java.net/browse/JDK-8065222
18-11-2014

the following stackoverflow article highlights a error return of ERROR_INSUFFICIENT_BUFFER rather than ERROR_BUFFER_OVERFLOW perhaps this is also an issue here http://stackoverflow.com/questions/12279135/error-insufficient-buffer-returned-from-getadaptersaddresses
17-11-2014