JDK-8182672 : Java 8u121 on Linux intermittently returns null for MAC address
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 8u121,9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2017-06-21
  • Updated: 2018-02-15
  • Resolved: 2017-06-23
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 10 JDK 8
10 b14Fixed 8u121Fixed
Related Reports
Relates :  
JDK-8156521 - Minor fixes and cleanups in NetworkInterface.c
Relates :  
JDK-8163181 - Further improvements for Unix NetworkInterface native implementation
Description
After updating from Java 8u101 to Java 8u121, Java application running with
Tomcat shows intermittent failure getting MAC address.  The application
connects to other apps on other systems by using MAC address to resolve IP
address for connection.  Intermittently, a thread will show a null MAC
address is returned and Tomcat log reports:

CRITICAL ERROR: ip address is not assigned to a valid ethernet interface.

The problem does not occur with single CPU/thread.  It occurs with multiple
CPUs/threads, under load.

The problem is not seen on Windows or MacOSX.

The problem is seen only on Linux systems using 8u121 or 8u131. The problem
does not occur when Java 8u101 is used on the same systems with the same
application version.  

Java 8u121 reproduces the issue at a lesser rate than 8u131.  The problem
takes about 50TPS on 8u121, but needs only a couple threads on 8u131 to
reproduce it.
Comments
I think it���s not necessarily the change from strcpy to memset/strncpy that causes the problem. That should actually be safer than before. I rather suppose the problem in this multithreaded environment of the test case is the static declaration of ifr. This should be changed to be a local variable, I suppose.
22-06-2017
reverting 2 lines in this change done via JDK-8156521 resolves the issue http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/c5c0728e113d#l1.1336 == - strcpy(ifr.ifr_name, ifname); + memset((char *)&ifr, 0, sizeof(ifr)); + strncpy(ifr.ifr_name, ifname, sizeof(ifr.ifr_name) - 1); ==
22-06-2017