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.
