RFR : 8182672: Java 8u121 on Linux intermittently returns null for MAC address

[Mark Sheppard]

Hi Sean,
   main change looks fine - it sorts the reported problem.

ran your test against jdk8 152 and a recent jdk9 builds to verify that 
your test failure occurs.
The failure is seen, together with an additional (intermittent) exception:

java.net.SocketException: No such device (ioctl(SIOCGIFHWADDR) failed)
at java.base/java.net.NetworkInterface.getMacAddr0(Native Method)
at 
java.base/java.net.NetworkInterface.getHardwareAddress(NetworkInterface.java:504)
at 
NetworkInterfaceGetMacAddressThreadedTest.run(NetworkInterfaceGetMacAddressThreadedTest.java:59)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1161)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:844)

The exception looks a bit confusing when mingled with test output. But this
doesn't occur in the fix version.

The exception is most likely a consequence of the non thread safe 
characteristic of the the current Linux
getMacAddress - what is actually in the ifr variable, when multiple 
threads are modifying it, when the  ioctl is called?
(who knows, who can tell, is this heaven, is this hell!!)

picked up you fix build and the test passes  fine,  as does the original 
test case reporting the issue.

also from a consistency perspective, the test is modifying two shared 
static variable
without synchronization. Maybe these should be volatile, at least?

regards
Mark

On 22/06/2017 17:29, Seán Coffey wrote:
> JDK 10 fix required to correct a race issue in NetworkInterface. I 
> don't believe the ifreq struct needs to be static in any case. New 
> auto unit testcase also. I propose to skip this fix for JDK 9 and fix 
> in an update release for that family. I also plan to port this to 
> jdk8u-dev.
>
> https://bugs.openjdk.java.net/browse/JDK-8182672
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8182672.jdk10/webrev/
>
> regards,
> Sean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20170622/b1811619/attachment.html>