Hi Sean,
i debug the failure and it look like you need to modify your test and
make it more robust. As Christoph suggested first call
"getHardwareAddress" and check if is not null then only iterate 100
time. This way your test will run on any platform and one minor comment
make your global
Hi Sean,
I played with it a bit more and now really understand Vyoms observation. So,
what he sees is not the original concurrency issue but he encounters a
SocketException on some interface, where this is supposed to occur upon calling
getHardwareAddress().
So, to enable the testcase to run
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
Hi Vyom,
thanks for testing. Null is a valid value for some interfaces. I've
excluded the loopback interface from being testing. Perhaps there's
other issues at play here. We know that getHardwareAddress() can throw
SocketException if I/O fails. For this particular scenario we're not
Hi Sean,
the patch to change the static declaration of struct ifreq ifr into a non
static declaration should be done in any case. I had suspected the issue should
disappear then but as Vyom told otherwise, I'll also try to test this.
As for the test: NetworkInterface.getNetworkInterfaces()
Hi Sean,
with your patch as well your test case is failing on my
laptop(Ubuntu16.04), when i tried to run on jdk8 i am getting below error.
java.net.SocketException: No such device (ioctl(SIOCGIFHWADDR) failed)
at java.net.NetworkInterface.getMacAddr0(Native Method)
at
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.
