Re: RFR [9] 8058216: NetworkInterface.getHardwareAddress can return zero length byte array when run with preferIPv4Stack
On 11/09/14 14:42, Chris Hegarty wrote:
A small issue was found when running JCK tests on modern Windows platforms,
that have IPv6 enabled, but forced to run with the IPv4 Stack,
-Djava.net.preferIPv4Stack=true. NetworkInterface.getHardwareAddress() can
return a zero length byte array, where is should, and is specified to, return
null.
The solution is to only create the byte array if the physical address is known.
Running an existing regression test with -Djava.net.preferIPv4Stack=true covers
this issue.
As was pointed out to me off list, the test should include this bug Id
too. It is now added, and some more context around the diffs, for easier
review.
---
diff --git a/src/java.base/windows/native/libnet/NetworkInterface.c
b/src/java.base/windows/native/libnet/NetworkInterface.c
--- a/src/java.base/windows/native/libnet/NetworkInterface.c
+++ b/src/java.base/windows/native/libnet/NetworkInterface.c
@@ -975,39 +975,41 @@
JNIEXPORT jbyteArray JNICALL Java_java_net_NetworkInterface_getMacAddr0
(JNIEnv *env, jclass class, jbyteArray addrArray, jstring name,
jint index) {
jbyteArray ret = NULL;
int len;
MIB_IFROW *ifRowP;
// Retained for now to support IPv4 only stack, java.net.preferIPv4Stack
if (ipv6_available()) {
return Java_java_net_NetworkInterface_getMacAddr0_XP(env, class,
name, index);
} else {
ifRowP = getIF(index);
if (ifRowP != NULL) {
switch(ifRowP->dwType) {
case MIB_IF_TYPE_ETHERNET:
case MIB_IF_TYPE_TOKENRING:
case MIB_IF_TYPE_FDDI:
case IF_TYPE_IEEE80211:
len = ifRowP->dwPhysAddrLen;
-ret = (*env)->NewByteArray(env, len);
-if (!IS_NULL(ret)) {
- (*env)->SetByteArrayRegion(env, ret, 0, len, (jbyte *)
ifRowP->bPhysAddr);
+if (len > 0) {
+ret = (*env)->NewByteArray(env, len);
+if (!IS_NULL(ret)) {
+ (*env)->SetByteArrayRegion(env, ret, 0, len, (jbyte *)
ifRowP->bPhysAddr);
+}
}
break;
}
free(ifRowP);
}
return ret;
}
}
$ hg diff test/java/net/NetworkInterface/Test.javadiff --git
a/test/java/net/NetworkInterface/Test.java
b/test/java/net/NetworkInterface/Test.java
--- a/test/java/net/NetworkInterface/Test.java
+++ b/test/java/net/NetworkInterface/Test.java
@@ -22,7 +22,9 @@
*/
/* @test
- * @bug 4405354 6594296
+ * @bug 4405354 6594296 8058216
+ * @run main Test
+ * @run main/othervm -Djava.net.preferIPv4Stack=true Test
* @summary Basic tests for NetworkInterface
*/
import java.net.NetworkInterface;
-Chris.
Re: RFR [9] 8058216: NetworkInterface.getHardwareAddress can return zero length byte array when run with preferIPv4Stack
Looks fine to me
Michael
On 12/09/14 10:05, Chris Hegarty wrote:
On 11/09/14 14:42, Chris Hegarty wrote:
A small issue was found when running JCK tests on modern Windows
platforms, that have IPv6 enabled, but forced to run with the IPv4
Stack, -Djava.net.preferIPv4Stack=true.
NetworkInterface.getHardwareAddress() can return a zero length byte
array, where is should, and is specified to, return null.
The solution is to only create the byte array if the physical address
is known. Running an existing regression test with
-Djava.net.preferIPv4Stack=true covers this issue.
As was pointed out to me off list, the test should include this bug Id
too. It is now added, and some more context around the diffs, for
easier review.
---
diff --git a/src/java.base/windows/native/libnet/NetworkInterface.c
b/src/java.base/windows/native/libnet/NetworkInterface.c
--- a/src/java.base/windows/native/libnet/NetworkInterface.c
+++ b/src/java.base/windows/native/libnet/NetworkInterface.c
@@ -975,39 +975,41 @@
JNIEXPORT jbyteArray JNICALL Java_java_net_NetworkInterface_getMacAddr0
(JNIEnv *env, jclass class, jbyteArray addrArray, jstring name,
jint index) {
jbyteArray ret = NULL;
int len;
MIB_IFROW *ifRowP;
// Retained for now to support IPv4 only stack,
java.net.preferIPv4Stack
if (ipv6_available()) {
return Java_java_net_NetworkInterface_getMacAddr0_XP(env, class,
name, index);
} else {
ifRowP = getIF(index);
if (ifRowP != NULL) {
switch(ifRowP->dwType) {
case MIB_IF_TYPE_ETHERNET:
case MIB_IF_TYPE_TOKENRING:
case MIB_IF_TYPE_FDDI:
case IF_TYPE_IEEE80211:
len = ifRowP->dwPhysAddrLen;
-ret = (*env)->NewByteArray(env, len);
-if (!IS_NULL(ret)) {
- (*env)->SetByteArrayRegion(env, ret, 0, len, (jbyte *)
ifRowP->bPhysAddr);
+if (len > 0) {
+ret = (*env)->NewByteArray(env, len);
+if (!IS_NULL(ret)) {
+ (*env)->SetByteArrayRegion(env, ret, 0, len, (jbyte *)
ifRowP->bPhysAddr);
+}
}
break;
}
free(ifRowP);
}
return ret;
}
}
$ hg diff test/java/net/NetworkInterface/Test.javadiff --git
a/test/java/net/NetworkInterface/Test.java
b/test/java/net/NetworkInterface/Test.java
--- a/test/java/net/NetworkInterface/Test.java
+++ b/test/java/net/NetworkInterface/Test.java
@@ -22,7 +22,9 @@
*/
/* @test
- * @bug 4405354 6594296
+ * @bug 4405354 6594296 8058216
+ * @run main Test
+ * @run main/othervm -Djava.net.preferIPv4Stack=true Test
* @summary Basic tests for NetworkInterface
*/
import java.net.NetworkInterface;
-Chris.
Re: RFR [9] 8058216: NetworkInterface.getHardwareAddress can return zero length byte array when run with preferIPv4Stack
Hello,
A short question out of couriosity, why is the code for the v6 and v4 case
different, anyway?
Gruss
Bernd
--
http://bernd.eckenfels.net
-Original Message-
From: Chris Hegarty
To: OpenJDK Network Dev list
Sent: Fr., 12 Sep 2014 11:05
Subject: Re: RFR [9] 8058216: NetworkInterface.getHardwareAddress can return
zero length byte array when run with preferIPv4Stack
On 11/09/14 14:42, Chris Hegarty wrote:
> A small issue was found when running JCK tests on modern Windows platforms,
> that have IPv6 enabled, but forced to run with the IPv4 Stack,
> -Djava.net.preferIPv4Stack=true. NetworkInterface.getHardwareAddress() can
> return a zero length byte array, where is should, and is specified to, return
> null.
>
> The solution is to only create the byte array if the physical address is
> known. Running an existing regression test with
> -Djava.net.preferIPv4Stack=true covers this issue.
As was pointed out to me off list, the test should include this bug Id
too. It is now added, and some more context around the diffs, for easier
review.
---
diff --git a/src/java.base/windows/native/libnet/NetworkInterface.c
b/src/java.base/windows/native/libnet/NetworkInterface.c
--- a/src/java.base/windows/native/libnet/NetworkInterface.c
+++ b/src/java.base/windows/native/libnet/NetworkInterface.c
@@ -975,39 +975,41 @@
JNIEXPORT jbyteArray JNICALL Java_java_net_NetworkInterface_getMacAddr0
(JNIEnv *env, jclass class, jbyteArray addrArray, jstring name,
jint index) {
jbyteArray ret = NULL;
int len;
MIB_IFROW *ifRowP;
// Retained for now to support IPv4 only stack, java.net.preferIPv4Stack
if (ipv6_available()) {
return Java_java_net_NetworkInterface_getMacAddr0_XP(env, class,
name, index);
} else {
ifRowP = getIF(index);
if (ifRowP != NULL) {
switch(ifRowP->dwType) {
case MIB_IF_TYPE_ETHERNET:
case MIB_IF_TYPE_TOKENRING:
case MIB_IF_TYPE_FDDI:
case IF_TYPE_IEEE80211:
len = ifRowP->dwPhysAddrLen;
-ret = (*env)->NewByteArray(env, len);
-if (!IS_NULL(ret)) {
- (*env)->SetByteArrayRegion(env, ret, 0, len, (jbyte *)
ifRowP->bPhysAddr);
+if (len > 0) {
+ret = (*env)->NewByteArray(env, len);
+if (!IS_NULL(ret)) {
+ (*env)->SetByteArrayRegion(env, ret, 0, len, (jbyte *)
ifRowP->bPhysAddr);
+}
}
break;
}
free(ifRowP);
}
return ret;
}
}
$ hg diff test/java/net/NetworkInterface/Test.javadiff --git
a/test/java/net/NetworkInterface/Test.java
b/test/java/net/NetworkInterface/Test.java
--- a/test/java/net/NetworkInterface/Test.java
+++ b/test/java/net/NetworkInterface/Test.java
@@ -22,7 +22,9 @@
*/
/* @test
- * @bug 4405354 6594296
+ * @bug 4405354 6594296 8058216
+ * @run main Test
+ * @run main/othervm -Djava.net.preferIPv4Stack=true Test
* @summary Basic tests for NetworkInterface
*/
import java.net.NetworkInterface;
-Chris.
Re: RFR [9] 8058216: NetworkInterface.getHardwareAddress can return zero length byte array when run with preferIPv4Stack
On 12/09/14 12:47, Bernd Eckenfels wrote: Hello, A short question out of couriosity, why is the code for the v6 and v4 case different, anyway? This is legacy code using Windows APIs that predate IPv6 support in the platform. There is a huge opportunity for cleanup and modernization here. Hopefully some of this can happen in the JDK 9 time frame, but for now I just want to put in a targeted fix for this specific issue, which is causing JCK failures on JDK 8u. -Chris.
