Add IDN support to existing net APIs

[Jonathan Lu]

Hi net-dev,

If a Java application tries to support International Domain Names (IDN)
[1], which was firstly brought in Java6,
 it has to write additional code or wrap java.net.IDN API [2] to make the
conversion each time it tries to resolve
a non-ASCII domain name, and use the converted punycode to make connections
to remote host, like:

java.net.IDN.toASCII("电脑.info <http://xn--wnyy6w.info>");

It is easier for newly writen applications, since a wrappers can be made in
early design stage, but if
it comes to existing Java applications and third-party libraries, IDN
support would involve much more effort
like modifying the existing code base, inspecting libraries
interfaces/implementations, or even
re-implement some of the functions.

I'm wondering if it is possible to add IDN support into existing Java APIs,
like
java.net.InetAddress.getByName(), if JDK itself supports IDN, any existing
applications or libraries would
benefit from supporting IDN automatically without any source code
modifications.

Of course there's security risks regarding IDN homograph attacks [1][2], so
it may not be a
good idea to change the default behavior right now. But it would still work
if a simple switch can be
added into current JDK.
For example, by defining following the property in command like options
like

-Djava.net.AutoIDN=true

Any existing Java applications who wishes to support IDN feature will be
able to support IDN
without any changes to its source code or re-compilation.

What's your opinion on this ? any comment is welcome.

Thank you

- Jonathan Lu

---

[1] http://en.wikipedia.org/wiki/Internationalized_domain_name
[2] http://download.java.net/jdk8/docs/api/java/net/IDN.html
[3] http://www.unicode.org/reports/tr36/
[4] http://en.wikipedia.org/wiki/IDN_homograph_attack

Re: Add IDN support to existing net APIs

[Jonathan Lu]

Hi Michael,

I'm wondering how we could move this forward.

For the next step, is it just to draft a JEP for this change as a beginning?
or should I get supports and approvals from some other groups or leaders ?

- Cheers
Jonathan


On Fri, Feb 21, 2014 at 1:32 AM, Michael McMahon <
michael.x.mcma...@oracle.com> wrote:

>  On 20/02/14 03:15, Jonathan Lu wrote:
>
>
> Hi Michael,
>
>  Thanks a lot for your comments.
>
> On Wed, Feb 19, 2014 at 6:28 PM, Michael McMahon <
> michael.x.mcma...@oracle.com> wrote:
>
>>  I think it's a good idea. Before changing anything though,
>> we would need to:
>>
>>1. identify all APIs that could potentially be affected and figure
>>out what is
>>needed for each. For instance:
>> 1. InetAddress
>>   2. SocketPermission
>>   3. URLPermission
>>   4. HttpURLConnection
>>   5. URL/URI
>>6. ...
>>
>>   Right, I assume all  APIs which accept string-represented host names
> would be affected.
> It that may not be a big change from point of view.
>
>>
>> 1.
>>1. understand how it relates to URIs and IRIs. I haven't looked
>>into this much
>>but it seems that there might be potential for confusion given that
>>these entities
>>have their own encoding schemes already. I'm sure the issues are all
>>well thrashed out
>>already, but I'd like to see exactly how it will work in Java before
>>we start the work
>>
>>   For the potential confusion, were you meaning a confusion between URI
> encoding (RFC-2396 [1]) and IDN ?
>
>
> Right. As I said, it may just be a matter of checking RFC2396 (or its
> successor RFC 3986).
> I think RFC 3986 references IDNs.
>
> Michael
>
>
>>
>> Maybe, the work is within the scope of a small JEP, if nothing else to
>> define the scope
>> of the work.
>>
>> Michael.
>>
>
>  Copying core-libs-dev and security-dev to get more comments.
>
>  Many thanks
>
>  - Jonathan
>
> [1] http://www.ietf.org/rfc/rfc2396.txt
>
>
>>
>>
>> On 19/02/14 04:00, Jonathan Lu wrote:
>>
>> Hi net-dev,
>>
>> If a Java application tries to support International Domain Names (IDN)
>> [1], which was firstly brought in Java6,
>>  it has to write additional code or wrap java.net.IDN API [2] to make the
>> conversion each time it tries to resolve
>> a non-ASCII domain name, and use the converted punycode to make
>> connections to remote host, like:
>>
>> java.net.IDN.toASCII("电 脑.info <http://xn--wnyy6w.info>");
>>
>>
>> It is easier for newly writen applications, since a wrappers can be made
>> in early design stage, but if
>> it comes to existing Java applications and third-party libraries, IDN
>> support would involve much more effort
>> like modifying the existing code base, inspecting libraries
>> interfaces/implementations, or even
>> re-implement some of the functions.
>>
>> I'm wondering if it is possible to add IDN support into existing Java
>> APIs, like
>> java.net.InetAddress.getByName(), if JDK itself supports IDN, any
>> existing applications or libraries would
>> benefit from supporting IDN automatically without any source code
>> modifications.
>>
>> Of course there's security risks regarding IDN homograph attacks [1][2],
>> so it may not be a
>> good idea to change the default behavior right now. But it would still
>> work if a simple switch can be
>> added into current JDK.
>> For example, by defining following the property in command like options
>> like
>>
>> -Djava.net.AutoIDN=true
>>
>> Any existing Java applications who wishes to support IDN feature will be
>> able to support IDN
>> without any changes to its source code or re-compilation.
>>
>> What's your opinion on this ? any comment is welcome.
>>
>> Thank you
>>
>> - Jonathan Lu
>>
>> ---
>>
>> [1] http://en.wikipedia.org/wiki/Internationalized_domain_name
>> [2] http://download.java.net/jdk8/docs/api/java/net/IDN.html
>> [3] http://www.unicode.org/reports/tr36/
>> [4] http://en.wikipedia.org/wiki/IDN_homograph_attack
>>
>>
>>
>
>

RFR 8043954: Fix behavior difference of connect() for AIX

[Jonathan Lu]

Hello,

Could I have following patch reviewed for bug 8034954 ?

http://cr.openjdk.java.net/~luchsh/JDK-8043954/

The patch is to fix a behavior difference of connect() API for AIX platform,
according to the documentation,
http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.commtrf2/connect.htm?lang=en

On AIX, when connect() got interrupted by signal, the underlying connection
will be made asynchronously,

"EINTR The attempt to establish a connection was interrupted by delivery of
a signal that was caught; the connection will be established
asynchronously."

This fix tries to poll() for successfully established connection or error
in the similar way as NET_Timeout().

Thanks
Jonathan

Re: RFR 8043954: Fix behavior difference of connect() for AIX

[Jonathan Lu]

Hi Volker,

Thanks for your comment! an updated webrev was made at
http://cr.openjdk.java.net/~luchsh/JDK-8043954.2/

On Tue, Jun 3, 2014 at 8:48 PM, Volker Simonis 
wrote:

> Hi Jonathan,
>
> thanks for fixing this! I've looked at the change and it looks good to
> me (but I'm not a reviewer).
> The only minor flaw I found is that you declare the helper variable
> 'int rc = -1' but never assign it. Instead you could just return '-1'
> directly where you currently return 'rc' and remove 'rc' altogether.
>

The new patch contains this change and another formatting change.


>
> I'm currently still doing test build and I'll run some tests. I'll let
> you know if I should see any problems.
>
> By the way - does this change fix a real problem or is it just an
> improvement of the current implementation (just curious)?
>

The change is now an improvement.


>
> Thank you and best regards,
> Volker
>
>
> On Tue, Jun 3, 2014 at 11:51 AM, Jonathan Lu 
> wrote:
> > Hello,
> >
> > Could I have following patch reviewed for bug 8034954 ?
> >
> > http://cr.openjdk.java.net/~luchsh/JDK-8043954/
> >
> > The patch is to fix a behavior difference of connect() API for AIX
> platform,
> > according to the documentation,
> >
> http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.commtrf2/connect.htm?lang=en
> >
> > On AIX, when connect() got interrupted by signal, the underlying
> connection
> > will be made asynchronously,
> >
> > "EINTR The attempt to establish a connection was interrupted by delivery
> of
> > a signal that was caught; the connection will be established
> > asynchronously."
> >
> > This fix tries to poll() for successfully established connection or error
> > in the similar way as NET_Timeout().
> >
> > Thanks
> > Jonathan
>

Thank you and best regards
Jonathan

Re: RFR 8043954: Fix behavior difference of connect() for AIX

[Jonathan Lu]

Hi Alan,

On Wed, Jun 4, 2014 at 9:16 PM, Alan Bateman 
wrote:

> On 04/06/2014 07:31, Jonathan Lu wrote:
>
>> Hi Volker,
>>
>> Thanks for your comment! an updated webrev was made at
>> http://cr.openjdk.java.net/~luchsh/JDK-8043954.2/
>>
>>  Would it make sense to set errno to sockopt_arg for the case that
> getsockopt(SO_ERROR) returns an error? Otherwise it looks okay to me.
>

If getsockopt(SO_ERROR) failed,  I did not find any explicit docs about the
behavior.
but as I tested with some C code snippet, the value of sockopt_arg would
not be changed if getsockopt(SO_ERROR) failed.
So I prefer to keep the current approach, does it make sense to you ?


>
> -Alan.
>

Many thanks
Jonathan

Re: RFR 8043954: Fix behavior difference of connect() for AIX

[Jonathan Lu]

Hi Alan,

On Fri, Jun 6, 2014 at 1:53 AM, Alan Bateman 
wrote:

>  On 05/06/2014 11:37, Jonathan Lu wrote:
>
>
>  If getsockopt(SO_ERROR) failed,  I did not find any explicit docs about
> the behavior.
> but as I tested with some C code snippet, the value of sockopt_arg would
> not be changed if getsockopt(SO_ERROR) failed.
>  So I prefer to keep the current approach, does it make sense to you ?
>
> The case that I was wondering about is the common case where
> getsockopt(SO_ERROR) succeeds and I was wondering if the code should
> actually be:
>
> if (sockopt_arg != 0 ) {
>   errno = sockopt_arg;
>   return -1;
> }
>
> That way the caller of NET_Connect will have errno set so that
> XXX_ThrowByNameWithLastError can create an appropriate exception message.
>


You are right! errno will be checked by other code if NET_Connect() failed,
I've updated the patch, please help to review.

http://cr.openjdk.java.net/~luchsh/JDK-8043954.3/



>
> -Alan.
>


Many thanks
- Jonathan

Re: RFR 8043954: Fix behavior difference of connect() for AIX

[Jonathan Lu]

Hi Alan, Volker,

Thanks a lot!
I've pushed the change.

Best regards
- Jonathan



On Fri, Jun 6, 2014 at 8:27 PM, Volker Simonis 
wrote:

> Hi Jonathan,
>
> I just wanted to let you know that I've build your changes on AIX 5..3 and
> 7.1.
> I've also run the jdk regression tests without specific issues.
>
> So thumbs up from me!
>
> Regards,
> Volker
>
>
> On Fri, Jun 6, 2014 at 12:03 PM, Jonathan Lu 
> wrote:
> > Hi Alan,
> >
> > On Fri, Jun 6, 2014 at 1:53 AM, Alan Bateman 
> > wrote:
> >
> >>  On 05/06/2014 11:37, Jonathan Lu wrote:
> >>
> >>
> >>  If getsockopt(SO_ERROR) failed,  I did not find any explicit docs about
> >> the behavior.
> >> but as I tested with some C code snippet, the value of sockopt_arg would
> >> not be changed if getsockopt(SO_ERROR) failed.
> >>  So I prefer to keep the current approach, does it make sense to you ?
> >>
> >> The case that I was wondering about is the common case where
> >> getsockopt(SO_ERROR) succeeds and I was wondering if the code should
> >> actually be:
> >>
> >> if (sockopt_arg != 0 ) {
> >>   errno = sockopt_arg;
> >>   return -1;
> >> }
> >>
> >> That way the caller of NET_Connect will have errno set so that
> >> XXX_ThrowByNameWithLastError can create an appropriate exception
> message.
> >>
> >
> >
> > You are right! errno will be checked by other code if NET_Connect()
> failed,
> > I've updated the patch, please help to review.
> >
> > http://cr.openjdk.java.net/~luchsh/JDK-8043954.3/
> >
> >
> >
> >>
> >> -Alan.
> >>
> >
> >
> > Many thanks
> > - Jonathan
>

Crash problem in net.dll

[Jonathan Lu]

Hello everybody,

I got one crash issue on OpenJDK7 windows build.

I captured the stack trace of such a crash, which happens intermittently 
on my 64bit Windows 2008 server. But unfortunately I have no simple test 
case to reproduce this problem.


RtlInterlockedFlushSList+0x2ea (0x779F2A7F [ntdll+0x32a7f])
RtlInterlockedFlushSList+0x572 (0x779F2D07 [ntdll+0x32d07])
RtlInterlockedFlushSList+0x45d (0x779F2BF2 [ntdll+0x32bf2])
HeapFree+0x14 (0x755A14D1 [kernel32+0x114d1])
free+0x1c (0x7284016A [msvcr100+0x1016a])
free_netaddr+0x11 (networkinterface.c:107, 0x725A12AC [net+0x12ac])
getAllInterfacesAndAddresses+0xb6 (networkinterface_winxp.c:199, 
0x725AB4C8 [net+0xb4c8])
Java_java_net_NetworkInterface_getAll_XP+0x12 
(networkinterface_winxp.c:693, 0x725AB7AB [net+0xb7ab])


From the code at 
src/windows/native/java/net/NetworkInterface_winXP.c:195, I believe it 
is the dangling pointers that caused this problem. The uninitialized 
pointer netaddrP is exceptionally freed if the call to Windows API 
"GetIpAddrTable()" fails.


So here's one proposed solution for this issue, can anybody please help 
to take a look?


diff -r 9b8c96f96a0f src/windows/native/java/net/NetworkInterface_winXP.c
--- a/src/windows/native/java/net/NetworkInterface_winXP.cMon Jun 27 
13:21:34 2011 -0700
+++ b/src/windows/native/java/net/NetworkInterface_winXP.cMon Aug 29 
14:59:09 2011 +0800

@@ -194,8 +194,7 @@
 while (curr != NULL) {
 netaddr *netaddrP;
 ret = enumAddresses_win(env, curr, &netaddrP);
-if ((*env)->ExceptionOccurred(env)) {
-free_netaddr(netaddrP);
+if (ret == -1) {
 return -1;
 }
 curr->addrs = netaddrP;

Best regards!


       Jonathan Lu

Re: Crash problem in net.dll

[Jonathan Lu]

Hi Michael,

Thanks for reminding, I checked the source under src/windows folder and 
found two more places to change.


Here's the updated patch:

diff -r 9b8c96f96a0f src/windows/native/java/net/NetworkInterface.c
--- a/src/windows/native/java/net/NetworkInterface.cMon Jun 27 
13:21:34 2011 -0700
+++ b/src/windows/native/java/net/NetworkInterface.cMon Aug 29 
17:02:56 2011 +0800

@@ -504,8 +504,7 @@
  */
 if (netaddrCount < 0) {
 netaddrCount = enumAddresses_win(env, ifs, &netaddrP);
-if ((*env)->ExceptionOccurred(env)) {
-free_netaddr(netaddrP);
+if (netaddrCount == -1) {
 return NULL;
 }
 }
diff -r 9b8c96f96a0f src/windows/native/java/net/NetworkInterface_winXP.c
--- a/src/windows/native/java/net/NetworkInterface_winXP.cMon Jun 27 
13:21:34 2011 -0700
+++ b/src/windows/native/java/net/NetworkInterface_winXP.cMon Aug 29 
17:02:56 2011 +0800

@@ -194,8 +194,7 @@
 while (curr != NULL) {
 netaddr *netaddrP;
 ret = enumAddresses_win(env, curr, &netaddrP);
-if ((*env)->ExceptionOccurred(env)) {
-free_netaddr(netaddrP);
+if (ret == -1) {
 return -1;
 }
 curr->addrs = netaddrP;
@@ -449,8 +448,7 @@
  */
 if (netaddrCount < 0) {
 netaddrCount = enumAddresses_win(env, ifs, &netaddrP);
-if ((*env)->ExceptionOccurred(env)) {
-free_netaddr(netaddrP);
+if (count == -1) {
 return NULL;
 }
 }

And from my point of view, such scenario may also appear in other parts, 
maybe a more thorough check is needed for all modules.


Regards!
- Jonathan Lu

On 08/29/2011 04:40 PM, Michael McMahon wrote:

Jonathan,

I think the change looks reasonable. But, we should make the equivalent
change at the other site where enumAddresses_win() is called in the 
same file.


- Michael.

On 29/08/11 09:14, Jonathan Lu wrote:

Hello everybody,

I got one crash issue on OpenJDK7 windows build.

I captured the stack trace of such a crash, which happens 
intermittently on my 64bit Windows 2008 server. But unfortunately I 
have no simple test case to reproduce this problem.


RtlInterlockedFlushSList+0x2ea (0x779F2A7F [ntdll+0x32a7f])
RtlInterlockedFlushSList+0x572 (0x779F2D07 [ntdll+0x32d07])
RtlInterlockedFlushSList+0x45d (0x779F2BF2 [ntdll+0x32bf2])
HeapFree+0x14 (0x755A14D1 [kernel32+0x114d1])
free+0x1c (0x7284016A [msvcr100+0x1016a])
free_netaddr+0x11 (networkinterface.c:107, 0x725A12AC [net+0x12ac])
getAllInterfacesAndAddresses+0xb6 (networkinterface_winxp.c:199, 
0x725AB4C8 [net+0xb4c8])
Java_java_net_NetworkInterface_getAll_XP+0x12 
(networkinterface_winxp.c:693, 0x725AB7AB [net+0xb7ab])


From the code at 
src/windows/native/java/net/NetworkInterface_winXP.c:195, I believe 
it is the dangling pointers that caused this problem. The 
uninitialized pointer netaddrP is exceptionally freed if the call to 
Windows API "GetIpAddrTable()" fails.


So here's one proposed solution for this issue, can anybody please 
help to take a look?


diff -r 9b8c96f96a0f 
src/windows/native/java/net/NetworkInterface_winXP.c
--- a/src/windows/native/java/net/NetworkInterface_winXP.cMon Jun 
27 13:21:34 2011 -0700
+++ b/src/windows/native/java/net/NetworkInterface_winXP.cMon Aug 
29 14:59:09 2011 +0800

@@ -194,8 +194,7 @@
 while (curr != NULL) {
 netaddr *netaddrP;
 ret = enumAddresses_win(env, curr, &netaddrP);
-if ((*env)->ExceptionOccurred(env)) {
-free_netaddr(netaddrP);
+if (ret == -1) {
 return -1;
 }
 curr->addrs = netaddrP;

Best regards!

   
Jonathan Lu

Re: Crash problem in net.dll

[Jonathan Lu]

Hi Michael,

Any news about the testing results of this patch?

Thanks
Jonathan

On 08/29/2011 11:02 PM, Michael McMahon wrote:

Just to be clear, I will run the tests on the fix and push the change
assuming everything is ok. There is a webrev here
http://cr.openjdk.java.net/~michaelm/7084560/webrev.1/

Thanks,
Michael.

On 29/08/11 15:33, Michael McMahon wrote:

Jonathan,

Bug id 7084560 has been created to track this. That fix looks fine
to me.

Thanks,
Michael.

On 29/08/11 10:20, Jonathan Lu wrote:

Hi Michael,

Thanks for reminding, I checked the source under src/windows folder 
and found two more places to change.


Here's the updated patch:

diff -r 9b8c96f96a0f src/windows/native/java/net/NetworkInterface.c
--- a/src/windows/native/java/net/NetworkInterface.cMon Jun 27 
13:21:34 2011 -0700
+++ b/src/windows/native/java/net/NetworkInterface.cMon Aug 29 
17:02:56 2011 +0800

@@ -504,8 +504,7 @@
  */
 if (netaddrCount < 0) {
 netaddrCount = enumAddresses_win(env, ifs, &netaddrP);
-if ((*env)->ExceptionOccurred(env)) {
-free_netaddr(netaddrP);
+if (netaddrCount == -1) {
 return NULL;
 }
 }
diff -r 9b8c96f96a0f 
src/windows/native/java/net/NetworkInterface_winXP.c
--- a/src/windows/native/java/net/NetworkInterface_winXP.cMon 
Jun 27 13:21:34 2011 -0700
+++ b/src/windows/native/java/net/NetworkInterface_winXP.cMon 
Aug 29 17:02:56 2011 +0800

@@ -194,8 +194,7 @@
 while (curr != NULL) {
 netaddr *netaddrP;
 ret = enumAddresses_win(env, curr, &netaddrP);
-if ((*env)->ExceptionOccurred(env)) {
-free_netaddr(netaddrP);
+if (ret == -1) {
 return -1;
 }
 curr->addrs = netaddrP;
@@ -449,8 +448,7 @@
  */
 if (netaddrCount < 0) {
 netaddrCount = enumAddresses_win(env, ifs, &netaddrP);
-if ((*env)->ExceptionOccurred(env)) {
-free_netaddr(netaddrP);
+if (count == -1) {
 return NULL;
 }
 }

And from my point of view, such scenario may also appear in other 
parts, maybe a more thorough check is needed for all modules.


Regards!
- Jonathan Lu

On 08/29/2011 04:40 PM, Michael McMahon wrote:

Jonathan,

I think the change looks reasonable. But, we should make the 
equivalent
change at the other site where enumAddresses_win() is called in the 
same file.


- Michael.

On 29/08/11 09:14, Jonathan Lu wrote:

Hello everybody,

I got one crash issue on OpenJDK7 windows build.

I captured the stack trace of such a crash, which happens 
intermittently on my 64bit Windows 2008 server. But unfortunately 
I have no simple test case to reproduce this problem.


RtlInterlockedFlushSList+0x2ea (0x779F2A7F [ntdll+0x32a7f])
RtlInterlockedFlushSList+0x572 (0x779F2D07 [ntdll+0x32d07])
RtlInterlockedFlushSList+0x45d (0x779F2BF2 [ntdll+0x32bf2])
HeapFree+0x14 (0x755A14D1 [kernel32+0x114d1])
free+0x1c (0x7284016A [msvcr100+0x1016a])
free_netaddr+0x11 (networkinterface.c:107, 0x725A12AC [net+0x12ac])
getAllInterfacesAndAddresses+0xb6 (networkinterface_winxp.c:199, 
0x725AB4C8 [net+0xb4c8])
Java_java_net_NetworkInterface_getAll_XP+0x12 
(networkinterface_winxp.c:693, 0x725AB7AB [net+0xb7ab])


From the code at 
src/windows/native/java/net/NetworkInterface_winXP.c:195, I 
believe it is the dangling pointers that caused this problem. The 
uninitialized pointer netaddrP is exceptionally freed if the call 
to Windows API "GetIpAddrTable()" fails.


So here's one proposed solution for this issue, can anybody please 
help to take a look?


diff -r 9b8c96f96a0f 
src/windows/native/java/net/NetworkInterface_winXP.c
--- a/src/windows/native/java/net/NetworkInterface_winXP.cMon 
Jun 27 13:21:34 2011 -0700
+++ b/src/windows/native/java/net/NetworkInterface_winXP.cMon 
Aug 29 14:59:09 2011 +0800

@@ -194,8 +194,7 @@
 while (curr != NULL) {
 netaddr *netaddrP;
 ret = enumAddresses_win(env, curr, &netaddrP);
-if ((*env)->ExceptionOccurred(env)) {
-free_netaddr(netaddrP);
+if (ret == -1) {
 return -1;
 }
 curr->addrs = netaddrP;

Best regards!

   
Jonathan Lu

Re: Crash problem in net.dll

[Jonathan Lu]

Aha, got it, thanks!

Jonathan.

On 09/07/2011 04:19 PM, Michael McMahon wrote:

Jonathan,

The tests were fine amd the fix was pushed last week.

Michael.

On 07/09/11 09:14, Jonathan Lu wrote:

Hi Michael,

Any news about the testing results of this patch?

Thanks
Jonathan

On 08/29/2011 11:02 PM, Michael McMahon wrote:

Just to be clear, I will run the tests on the fix and push the change
assuming everything is ok. There is a webrev here
http://cr.openjdk.java.net/~michaelm/7084560/webrev.1/

Thanks,
Michael.

On 29/08/11 15:33, Michael McMahon wrote:

Jonathan,

Bug id 7084560 has been created to track this. That fix looks fine
to me.

Thanks,
Michael.

On 29/08/11 10:20, Jonathan Lu wrote:

Hi Michael,

Thanks for reminding, I checked the source under src/windows 
folder and found two more places to change.


Here's the updated patch:

diff -r 9b8c96f96a0f src/windows/native/java/net/NetworkInterface.c
--- a/src/windows/native/java/net/NetworkInterface.cMon Jun 27 
13:21:34 2011 -0700
+++ b/src/windows/native/java/net/NetworkInterface.cMon Aug 29 
17:02:56 2011 +0800

@@ -504,8 +504,7 @@
  */
 if (netaddrCount < 0) {
 netaddrCount = enumAddresses_win(env, ifs, &netaddrP);
-if ((*env)->ExceptionOccurred(env)) {
-free_netaddr(netaddrP);
+if (netaddrCount == -1) {
 return NULL;
 }
 }
diff -r 9b8c96f96a0f 
src/windows/native/java/net/NetworkInterface_winXP.c
--- a/src/windows/native/java/net/NetworkInterface_winXP.cMon 
Jun 27 13:21:34 2011 -0700
+++ b/src/windows/native/java/net/NetworkInterface_winXP.cMon 
Aug 29 17:02:56 2011 +0800

@@ -194,8 +194,7 @@
 while (curr != NULL) {
 netaddr *netaddrP;
 ret = enumAddresses_win(env, curr, &netaddrP);
-if ((*env)->ExceptionOccurred(env)) {
-free_netaddr(netaddrP);
+if (ret == -1) {
 return -1;
 }
 curr->addrs = netaddrP;
@@ -449,8 +448,7 @@
  */
 if (netaddrCount < 0) {
 netaddrCount = enumAddresses_win(env, ifs, &netaddrP);
-if ((*env)->ExceptionOccurred(env)) {
-free_netaddr(netaddrP);
+if (count == -1) {
 return NULL;
 }
 }

And from my point of view, such scenario may also appear in other 
parts, maybe a more thorough check is needed for all modules.


Regards!
- Jonathan Lu

On 08/29/2011 04:40 PM, Michael McMahon wrote:

Jonathan,

I think the change looks reasonable. But, we should make the 
equivalent
change at the other site where enumAddresses_win() is called in 
the same file.


- Michael.

On 29/08/11 09:14, Jonathan Lu wrote:

Hello everybody,

I got one crash issue on OpenJDK7 windows build.

I captured the stack trace of such a crash, which happens 
intermittently on my 64bit Windows 2008 server. But 
unfortunately I have no simple test case to reproduce this problem.


RtlInterlockedFlushSList+0x2ea (0x779F2A7F [ntdll+0x32a7f])
RtlInterlockedFlushSList+0x572 (0x779F2D07 [ntdll+0x32d07])
RtlInterlockedFlushSList+0x45d (0x779F2BF2 [ntdll+0x32bf2])
HeapFree+0x14 (0x755A14D1 [kernel32+0x114d1])
free+0x1c (0x7284016A [msvcr100+0x1016a])
free_netaddr+0x11 (networkinterface.c:107, 0x725A12AC [net+0x12ac])
getAllInterfacesAndAddresses+0xb6 (networkinterface_winxp.c:199, 
0x725AB4C8 [net+0xb4c8])
Java_java_net_NetworkInterface_getAll_XP+0x12 
(networkinterface_winxp.c:693, 0x725AB7AB [net+0xb7ab])


From the code at 
src/windows/native/java/net/NetworkInterface_winXP.c:195, I 
believe it is the dangling pointers that caused this problem. 
The uninitialized pointer netaddrP is exceptionally freed if the 
call to Windows API "GetIpAddrTable()" fails.


So here's one proposed solution for this issue, can anybody 
please help to take a look?


diff -r 9b8c96f96a0f 
src/windows/native/java/net/NetworkInterface_winXP.c
--- a/src/windows/native/java/net/NetworkInterface_winXP.c
Mon Jun 27 13:21:34 2011 -0700
+++ b/src/windows/native/java/net/NetworkInterface_winXP.c
Mon Aug 29 14:59:09 2011 +0800

@@ -194,8 +194,7 @@
 while (curr != NULL) {
 netaddr *netaddrP;
 ret = enumAddresses_win(env, curr, &netaddrP);
-if ((*env)->ExceptionOccurred(env)) {
-free_netaddr(netaddrP);
+if (ret == -1) {
 return -1;
 }
 curr->addrs = netaddrP;

Best regards!

   
Jonathan Lu

java.net.NetworkInterface.getNetworkInterfaces does not work properly on AIX with IPv6

[Jonathan Lu]

Hi net-devs,

I've got a problem on AIX operating system when IPv6 is enabled,which 
can be easily reproduced by attached test case NetworkInterfaceTest.java.
On AIX paltform, the /proc file system behaves differently from Linux, 
so we cannot just read required lines from /proc/net/if_inet6 but to 
call ioctl to get needed information. A patch is available for OpenJDK8 
code base, see attachment patch.diff.


Is anybody interested in this topic?

I'm quite aware of the fact that so far there's no publicly available 
building scripts for OpenJDK8 on AIX operating system, but before 
everything settles down, is anybody willing to review the patch? any 
ideas about how to integrate it?


Best regards!

/* This test checks if the interface's addresses returned by getNetworkInterfaces are unique */

import java.net.*;
import java.util.*;

public class NetworkInterfaceTest {
	java.net.NetworkInterface pnics;
	java.util.Enumeration nics1;

	NetworkInterfaceTest() {
		java.net.NetworkInterface jnic;
		java.util.Enumeration nics;
		List lst = new ArrayList();
		List lst1 = new ArrayList();

		try {
			nics = java.net.NetworkInterface.getNetworkInterfaces();
			while (nics.hasMoreElements()) {
jnic = (java.net.NetworkInterface) nics.nextElement();
lst = jnic.getInterfaceAddresses();
nics1 = jnic.getInetAddresses();
while (nics1.hasMoreElements()) {
	InetAddress addr1 = (InetAddress) nics1.nextElement();
	if (!(lst1.contains(addr1))) {
		lst1.add(addr1);
	}
}
if(lst.size() != lst1.size()){
System.out.println(this.getClass().getName()+" failed!");
}else{
System.out.println(this.getClass().getName()+" passed!");
}
lst1.clear();
			}
		} catch (java.lang.Exception e) {
			e.printStackTrace();
		}
	}

public static void main(String[] args) {
new NetworkInterfaceTest();
}
}


diff -r 7539cc99befe src/solaris/native/java/net/NetworkInterface.c
--- a/src/solaris/native/java/net/NetworkInterface.c	Thu Oct 13 10:35:43 2011 -0700
+++ b/src/solaris/native/java/net/NetworkInterface.c	Fri Oct 14 17:44:02 2011 +0800
@@ -22,6 +22,8 @@
  * or visit www.oracle.com if you need additional information or have any
  * questions.
  */
+#define MAX(x,y) ((x) > (y) ? (x) : (y))
+#define SIZE(p) MAX((p).sa_len, sizeof(p))
 
 
 #include 
@@ -1095,12 +1097,96 @@
 return ifs;
 }
 
-
+#if defined(AF_INET6)   
+#if defined(AIX) 
+/*  
+ * Enumerates and returns all IPv6 interfaces on AIX  
+ */  
+static netif *enumIPv6Interfaces(JNIEnv *env, int sock, netif *ifs) { 
+struct ifconf ifc;  
+struct ifreq *ifreqP;  
+char *buf;  
+int numifs; 
+unsigned i; 
+unsigned bufsize;   
+char *cp, *cplimit;
+
+/* use SIOCGSIZIFCONF to get size for  SIOCGIFCONF */   
+
+ifc.ifc_buf = NULL;  
+if (ioctl(sock, SIOCGSIZIFCONF, &(ifc.ifc_len)) < 0) {  
+NET_ThrowByNameWithLastError(env , JNU_JAVANETPKG "SocketException", 
+"ioctl SIOCGSIZIFCONF failed");  
+return ifs; 
+}  
+bufsize = ifc.ifc_len; 
+
+buf = (char *)malloc(bufsize);  
+if (!buf) { 
+JNU_ThrowOutOfMemoryError(env, "Network interface native buffer allocation failed");  
+return ifs;
+} 
+ifc.ifc_len = bufsize; 
+ifc.ifc_buf = buf;  
+if (ioctl(sock, SIOCGIFCONF, (char *)&ifc) < 0) {  
+NET_ThrowByNameWithLastError(env , JNU_JAVANETPKG "So

Re: java.net.NetworkInterface.getNetworkInterfaces does not work properly on AIX with IPv6

[Jonathan Lu]

On 10/19/2011 06:03 PM, Steve Poole wrote:

On Mon, 2011-10-17 at 15:14 +0800, Jonathan Lu wrote:

Hi net-devs,

I've got a problem on AIX operating system when IPv6 is enabled,which
can be easily reproduced by attached test case NetworkInterfaceTest.java.
On AIX paltform, the /proc file system behaves differently from Linux,
so we cannot just read required lines from /proc/net/if_inet6 but to
call ioctl to get needed information. A patch is available for OpenJDK8
code base, see attachment patch.diff.

Is anybody interested in this topic?

I'm quite aware of the fact that so far there's no publicly available
building scripts for OpenJDK8 on AIX operating system, but before
everything settles down, is anybody willing to review the patch? any
ideas about how to integrate it?

Best regards!


Hi Jonathan -  can you add a copyright header to the testcase and see if
you can make the testcase fit into a jtreg test format?




Hi Steve,
Thanks for your suggestion.
I've updated the test case to fit into a jtreg format, see the 
attachment NetworkInterfaceTest.java.


- Jonathan
/*
 * Copyright (c) 2008, 2011, Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.  Oracle designates this
 * particular file as subject to the "Classpath" exception as provided
 * by Oracle in the LICENSE file that accompanied this code.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

import java.net.*;
import java.util.*;

/* @test NetworkInterfaceTest
 * @summary java.net.NetworkInterface.getNetworkInterfaces() does not work properly on AIX with IPv6
 */

public class NetworkInterfaceTest {
java.net.NetworkInterface pnics;
java.util.Enumeration nics1;

NetworkInterfaceTest() throws Exception{
java.net.NetworkInterface jnic;
java.util.Enumeration nics;
List lst = new ArrayList();
List lst1 = new ArrayList();

try {
nics = java.net.NetworkInterface.getNetworkInterfaces();
while (nics.hasMoreElements()) {
jnic = (java.net.NetworkInterface) nics.nextElement();
lst = jnic.getInterfaceAddresses();
nics1 = jnic.getInetAddresses();
while (nics1.hasMoreElements()) {
InetAddress addr1 = (InetAddress) nics1.nextElement();
if (!(lst1.contains(addr1))) {
lst1.add(addr1);
}
}

if(lst.size() != lst1.size()){
throw new Exception("NetworkInterfaceTest Failed");
}

lst1.clear();
}
} catch (java.lang.Exception e) {
e.printStackTrace();
}
}

public static void main(String[] args) throws Exception{
new NetworkInterfaceTest();
}
}

Re: java.net.NetworkInterface.getNetworkInterfaces does not work properly on AIX with IPv6

[Jonathan Lu]

On 10/20/2011 01:24 PM, Jonathan Lu wrote:

On 10/19/2011 06:03 PM, Steve Poole wrote:

On Mon, 2011-10-17 at 15:14 +0800, Jonathan Lu wrote:

Hi net-devs,

I've got a problem on AIX operating system when IPv6 is enabled,which
can be easily reproduced by attached test case 
NetworkInterfaceTest.java.

On AIX paltform, the /proc file system behaves differently from Linux,
so we cannot just read required lines from /proc/net/if_inet6 but to
call ioctl to get needed information. A patch is available for OpenJDK8
code base, see attachment patch.diff.

Is anybody interested in this topic?

I'm quite aware of the fact that so far there's no publicly available
building scripts for OpenJDK8 on AIX operating system, but before
everything settles down, is anybody willing to review the patch? any
ideas about how to integrate it?

Best regards!


Hi Jonathan -  can you add a copyright header to the testcase and see if
you can make the testcase fit into a jtreg test format?




Hi Steve,
Thanks for your suggestion.
I've updated the test case to fit into a jtreg format, see the 
attachment NetworkInterfaceTest.java.


- Jonathan


Here's an updated test case with a more clear copyright header.

- Jonathan
/*
 * Copyright (c) 2011 Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

/*
 * Portions Copyright (c) 2011 IBM Corporation
 */

import java.net.*;
import java.util.*;

/* @test NetworkInterfaceTest
 * @summary java.net.NetworkInterface.getNetworkInterfaces() does not work properly on AIX with IPv6
 */

public class NetworkInterfaceTest {
java.net.NetworkInterface pnics;
java.util.Enumeration nics1;

NetworkInterfaceTest() throws Exception{
java.net.NetworkInterface jnic;
java.util.Enumeration nics;
List lst = new ArrayList();
List lst1 = new ArrayList();

try {
nics = java.net.NetworkInterface.getNetworkInterfaces();
while (nics.hasMoreElements()) {
jnic = (java.net.NetworkInterface) nics.nextElement();
lst = jnic.getInterfaceAddresses();
nics1 = jnic.getInetAddresses();
while (nics1.hasMoreElements()) {
InetAddress addr1 = (InetAddress) nics1.nextElement();
if (!(lst1.contains(addr1))) {
lst1.add(addr1);
}
}

if(lst.size() != lst1.size()){
throw new Exception("NetworkInterfaceTest Failed");
}

lst1.clear();
}
} catch (java.lang.Exception e) {
e.printStackTrace();
}
}

public static void main(String[] args) throws Exception{
new NetworkInterfaceTest();
}
}

Re: java.net.NetworkInterface.getNetworkInterfaces does not work properly on AIX with IPv6

[Jonathan Lu]

On 10/20/2011 02:35 PM, Steve Poole wrote:

On Thu, 2011-10-20 at 13:24 +0800, Jonathan Lu wrote:

On 10/19/2011 06:03 PM, Steve Poole wrote:

On Mon, 2011-10-17 at 15:14 +0800, Jonathan Lu wrote:

Hi net-devs,

I've got a problem on AIX operating system when IPv6 is enabled,which
can be easily reproduced by attached test case NetworkInterfaceTest.java.
On AIX paltform, the /proc file system behaves differently from Linux,
so we cannot just read required lines from /proc/net/if_inet6 but to
call ioctl to get needed information. A patch is available for OpenJDK8
code base, see attachment patch.diff.

Is anybody interested in this topic?

I'm quite aware of the fact that so far there's no publicly available
building scripts for OpenJDK8 on AIX operating system, but before
everything settles down, is anybody willing to review the patch? any
ideas about how to integrate it?

Best regards!

Hi Jonathan -  can you add a copyright header to the testcase and see if
you can make the testcase fit into a jtreg test format?


Hi Steve,
Thanks for your suggestion.
I've updated the test case to fit into a jtreg format, see the
attachment NetworkInterfaceTest.java.

Cool - at a quick glance it looks fine - except your're missing the IBM
attribution comment.  I'll send you the details.


- Jonathan

Thanks Steve, I've updated the test case and patch, see the attachments.
I've added IBM portions copyright comment to both headers.

- Jonathan
/*
 * Copyright (c) 2011 Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

/*
 * Portions Copyright (c) 2011 IBM Corporation
 */

import java.net.*;
import java.util.*;

/* @test NetworkInterfaceTest
 * @summary java.net.NetworkInterface.getNetworkInterfaces() does not work properly on AIX with IPv6
 */

public class NetworkInterfaceTest {
java.net.NetworkInterface pnics;
java.util.Enumeration nics1;

NetworkInterfaceTest() throws Exception{
java.net.NetworkInterface jnic;
java.util.Enumeration nics;
List lst = new ArrayList();
List lst1 = new ArrayList();

try {
nics = java.net.NetworkInterface.getNetworkInterfaces();
while (nics.hasMoreElements()) {
jnic = (java.net.NetworkInterface) nics.nextElement();
lst = jnic.getInterfaceAddresses();
nics1 = jnic.getInetAddresses();
while (nics1.hasMoreElements()) {
InetAddress addr1 = (InetAddress) nics1.nextElement();
if (!(lst1.contains(addr1))) {
lst1.add(addr1);
}
}

if(lst.size() != lst1.size()){
throw new Exception("NetworkInterfaceTest Failed");
}

lst1.clear();
}
} catch (java.lang.Exception e) {
e.printStackTrace();
}
}

public static void main(String[] args) throws Exception{
new NetworkInterfaceTest();
}
}
diff -r 4788745572ef -r d7cd8c7c05af src/solaris/native/java/net/NetworkInterface.c
--- a/src/solaris/native/java/net/NetworkInterface.c	Mon Oct 17 19:06:53 2011 -0700
+++ b/src/solaris/native/java/net/NetworkInterface.c	Thu Oct 20 16:54:37 2011 +0800
@@ -23,6 +23,13 @@
  * questions.
  */
 
+/*
+ * Portions Copyright (c) 2011 IBM Corporation
+ */
+
+#define MAX(x,y) ((x) > (y) ? (x) : (y))
+#define SIZE(p) MAX((p).sa_len, sizeof(p))
+
 
 #include 
 #include 
@@ -1095,12 +1102,96 @@
 return ifs;
 }
 
-
+#if defined(AF_INET6)   
+#if defined(AIX) 
+/*  
+ * Enumerates and returns all IPv6 interfaces on AIX  
+ */  
+static netif *enumIPv6Interfaces(JNIEnv *env, int sock, neti

Re: java.net.NetworkInterface.getNetworkInterfaces does not work properly on AIX with IPv6

[Jonathan Lu]

On 10/20/2011 09:16 PM, Neil Richards wrote:

On Thu, 2011-10-20 at 17:12 +0800, Jonathan Lu wrote:

On 10/20/2011 02:35 PM, Steve Poole wrote:
Thanks Steve, I've updated the test case and patch, see the attachments.
I've added IBM portions copyright comment to both headers.

- Jonathan

For ease of review, I've uploaded the suggested fix as a webrev [1].

Whilst creating this, I stripped the (large amount of) extraneous
trailing whitespace characters from the lines added by the patch.
(It would be helpful to check for this when posting patches).


Thanks Neil for creating that webrev.
I'm sorry for the whitespace issue, I did not 'set list' in my VIM 
editor before, will turn on that option from now on. Attachment 
patch.diff is an updated version.

Looking at the change, I have some concerns.

Firstly, the added AIX-specific code (between lines 1102-1187) has been
placed in a block of code that looks to be Linux-specific (lines
1013-1365, protected by '#ifdef __linux__').

So it's unclear why any of this code will be used by AIX.

To be clear, I've moved the AIX code of enumIPv6Interfaces to a stand 
alone '#ifdef AIX' block.

Secondly, if an exception occurs whilst the list of interfaces is being
compiled, both Linux and Solaris look to return the list compiled up to
the point of the exception (blocks starting at lines 1222&  1505).

In the suggested AIX code, however, the compiled interface list is freed
up in this situation, and NULL returned (block starting at line 1174).

It seems to me that these routines should present similar semantics
(across the 3 platforms).
As the interface list returned is an augmentation of an interface list
that is originally given to the function (the original value of 'ifs'),
the suggested AIX code may free off entries in the list that it was not
responsible for allocating, which runs the risk of resulting in
duplicate calls to free().

Could you please investigate where the responsibilities properly lie for
allocation and deallocation of the entries in the interface list given
to the enumIPv6Interfaces() function, then update the proposal /
comments appropriately?
For the exception handling part, I think AIX implementation works in the 
same way as enumIPv4Interfaces on Linux platform.


Although the interface list returned is an argument given to this 
function (known as 'ifs'), this pointer is modified by addif() function 
which may add a new node to the head of the list, so the value of this 
pointer changes in this function.
And if NULL is return by AIX version enumIPv6Interfaces(), then the 
interface list pointer 'ifs' from caller function (here is 
'enumInterfaces') will be set to NULL which will just skip the next 
freeif() operation. So from my point of view, I do not see any potential 
duplicate calls to free().



Also, I'm concerned that the name of the testcase provided is overly
vague (what _specifically_ about NetworkInterface does it test?), and
that the @summary description does not describe what the intention of
the test is.
In particular, there is nothing platform-specific about the testcase, so
I would not expect its description to be in terms of something
AIX-specific.

Yes, the testcase is nothing platform-specific, I've updated the name 
and summary.

How about changing the name to NetworkInterfaceUniquenessTest?

Hope this helps,
Regards, Neil

[1]http://cr.openjdk.java.net/~ngmr/ojdk-172/webrev.00/



/*
 * Copyright (c) 2011 Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

/*
 * Portions Copyright (c) 2011 IBM Corporation
 */

import java.net.*;
import java.util.*;

/* @test NetworkInterfaceTest
 * @summary This test checks if the interface's addresses returned by getNetworkInterfaces are unique
 */

public class NetworkInterfaceUniquenessTest {
java.net.NetworkInterface pnics;
java.util.Enumeration nics1;

NetworkInterfaceTest() throws Exception{
 

Re: Question about getaddrinfo in Inet4AddressImpl.c

[Jonathan Lu]

Hello Chris,

On 10/25/2011 05:41 PM, Chris Hegarty wrote:


On 10/25/11 08:31 AM, Charles Lee wrote:

Hi guys,

I am reading some native code in the jdk repos. I find that in
Inet4AddressImpl.c (folder solaris), gethostbyname is used. Meanwhile in
the Inet6AddressImpl.c. getaddrinfo is used. My question is why inet4
does not use getaddrinfo? Any concern here?


The Inet4AddressImpl implementation clearly only needs to deal with 
IPv4 addresses, so gethostbyname is sufficient. Historically, when 
this code was added way back we couldn't be guaranteed that the IPv6 
API's would be available on all platforms.


getaddrinfo is now part of POSIX standard, and gethostbyname was removed 
from POSIX specification by POSIX.1-2008. So the suggested change is a 
latest-POSIX-compatible change.
Moreover getaddrinfo supports IPv4 too, so I think it will not bring any 
additional dependencies on an platform without IPv6, right?
We do still support building without IPv6 and I would be reluctant to 
to put a dependency from Inet4AddressImpl on getaddrinfo for this reason.


If your specific issue is with __GLIBC__, I wonder if it could be 
replaced with __LINUX__?? We'd need to look more into this.


-Chris.



There are some pros I can see if getaddrinfo is used in the
Inet4AddressImpl:
1. Code will look more clean and portable :-)
2. __GLIBC__ can be omitted. I have grep the __GLIBC__ in the jdk/src
directories, only Inet4AddressImpl use it.

Re: A little modification to error message

[Jonathan Lu]

Hi Sean,

Patch committed

Changeset: 15a6b0bceb1e
Author:zhouyx
Date:  2012-07-06 10:36 +0800
URL:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/15a6b0bceb1e

7181353: Update error message to distinguish native OOM and java OOM in net
Reviewed-by: chegar

! src/solaris/native/java/net/Inet4AddressImpl.c
! src/solaris/native/java/net/Inet6AddressImpl.c
! src/solaris/native/java/net/NetworkInterface.c
! src/solaris/native/java/net/PlainDatagramSocketImpl.c
! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c
! src/windows/native/java/net/Inet6AddressImpl.c
! src/windows/native/java/net/NetworkInterface.c
! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c


Please verify

Regards
Jonathan

On 07/03/2012 02:10 PM, Sean Chou wrote:


A bug is reported. 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181353 .


On Mon, Jul 2, 2012 at 3:57 PM, Chris Hegarty 
mailto:chris.hega...@oracle.com>> wrote:


Thanks Sean, looks fine to me.

-Chris

Sean Chou mailto:zho...@linux.vnet.ibm.com>> wrote:

>Hello,
>
>Any one would like to take a look again ?
>
>-- Forwarded message --
>From: Sean Chou mailto:zho...@linux.vnet.ibm.com>>
>Date: Tue, Jun 26, 2012 at 1:03 PM
>Subject: Re: A little modification to error message
>To: Chris Hegarty mailto:chris.hega...@oracle.com>>
>Cc: net-dev@openjdk.java.net 
>
>
>Hi Chris,
>
>They are not all native OOMs, I made a new one which includes
all of
>them. Please take a look.
>
>webrev: http://cr.openjdk.java.net/~zhouyx/OJDK-528/webrev.01/

>
>
>On Thu, Jun 21, 2012 at 5:23 PM, Chris Hegarty
mailto:chris.hega...@oracle.com>>
> wrote:
>
>> Sean,
>>
>> The updated error messages look fine to me.
>>
>> Are these all the possibly native OOM throw sites in the
networking area,
>> or just some you came across?
>>
>> -Chris.
>>
>>
>> On 21/06/2012 06:41, Sean Chou wrote:
>>
>>> Hi all,
>>>
>>> We did some modification in these error messages because
of some
>>> user feedback “It is confusing to realize if the OOM is from
java heap
>>> or native heap”. So these error messages are modified from "heap
>>> allocation failed" to "Native heap allocation failed". And in some
>>> places a little more to help locate to functions like "send
buffer heap
>>> allocation failed".
>>> Would any one like to take a look?
>>>
>>> webrev:
http://cr.openjdk.java.net/~**zhouyx/OJDK-528/webrev.00/

>
>>>   .
>>>
>>> --
>>> Best Regards,
>>> Sean Chou
>>>
>>>
>
>
>--
>Best Regards,
>Sean Chou
>
>
>
>
>--
>Best Regards,
>Sean Chou




--
Best Regards,
Sean Chou

Re: Suggestion of combining some macros of processing solaris, macosx with other UNIX

[Jonathan Lu]

On 08/17/2012 04:14 PM, Chris Hegarty wrote:

On 16/08/12 10:21, Frank Ding wrote:


Hi Chris and Alan,
   Thank you for taking time to help this issue.  I have built using
latest openjdk 8 repo on Windows 64 and Linux 32/64.  Since it's a macro
change in path "src/solaris", I only did jtreg tests for Linux 32 and 64
build.  The jtreg tests I ran are restricted to package "java/net".
Please let me know if you need me to do more tests or on more platforms
(such as Solaris).


I ran some builds and tests on all ( Solaris, Linux & Mac ) platforms. 
All looks good.


You can list me as a reviewer. I can push this for you, or can have 
someone else from IBM do the push, just let me know.


Thanks for the contribution,
-Chris.



Best regards,
Frank




Hello Chris,

Thanks for review, I've pushed the change @ 
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4993f8aa7f2e


changeset:   5704:4993f8aa7f2e
tag: tip
user:dingxmin
date:Fri Aug 17 17:10:56 2012 +0800
files:   src/solaris/native/java/net/PlainDatagramSocketImpl.c
description:
7191275: Cleanup OS specific blocks in PlainDatagramSocketImpl.c to 
support more unix-like platforms

Reviewed-by: chegar

And to Frank, pls verify the change set.

Thanks
Jonathan

Re: Request for code review 6512101: Incorrect encoding in NetworkInterface.getDisplayName()

[Jonathan Lu]

Hi Frank,

Patch pushed @ http://hg.openjdk.java.net/jdk8/tl/jdk/rev/883feced1cdd

Best regards!
- Jonathan

On 12/11/2012 09:49 AM, Frank Ding wrote:

Hi All,
  Thank you all.  I will have Jonathan help to commit.

Best regards,
Frank

On 12/10/2012 6:12 PM, Chris Hegarty wrote:

On 10/12/2012 08:01, Dmitry Samersoff wrote:

Frank,

Excellent! Thank you for doing it.


Ditto, thanks Frank.

I assume Sean or Neil will push this for you? Otherwise, just let me 
know and I can do it.


-Chris.



-Dmitry

On 2012-12-10 12:00, Frank Ding wrote:

Hi Dmitry,
   I updated wording accordingly @
http://cr.openjdk.java.net/~dingxmin/6512101/webrev.03.  It is now
changed to "Cannot get multibyte char for interface display name".  
What

about that?

Best regards,
Frank

On 12/10/2012 3:43 PM, Dmitry Samersoff wrote:

Frank,

Looks good for me.

May be "Can't get WIDE string" should be changed to something more
verbose.

-Dmitry


On 2012-12-10 11:40, Frank Ding wrote:

Hi Dmitry and Chris,
Could you please review the second revision again?

Thanks and Best regards,
Frank
On 11/29/2012 1:08 PM, Frank Ding wrote:

Hi Dmitry and Chris,
Thanks for your comments.  With your comments incorporated, 
I've

prepared v2 @
http://cr.openjdk.java.net/~dingxmin/6512101/webrev.02/. Could you
please review it again?

Best regards,
Frank

On 11/14/2012 12:12 AM, Chris Hegarty wrote:

On 11/11/2012 07:03 PM, Dmitry Samersoff wrote:

Frank,

Changes look good for me.

I admit that I am not an expert in this area, but given the
information you provided, and I guess you verified this in your
environment, the conversion would appear reasonable.


But it might be better to fall back to original behavior if
MultiByteToWideChar return error, rather than abort.
I agree with Dmitry, fall back would be preferable. Can you 
make the

changes and post an updated webrev.

-Chris.


-Dmitry

On 2012-11-07 13:08, Frank Ding wrote:

Hi guys,
 Could you please take a look at patch below aimed to 
resolve

existing
bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512101 ?
http://cr.openjdk.java.net/~dingxmin/6512101/webrev.01/

 I happen to have a Chinese Win 7 environment. 
"buggy.png" is

current
output of test case described in bug system whereas "fixed.png"
is the
output after the my patch is applied.

http://cr.openjdk.java.net/~dingxmin/6512101/buggy.png
http://cr.openjdk.java.net/~dingxmin/6512101/fixed.png

 The patch simply converts to wide chars encoded in 
CP_OEMCP by

calling
MultiByteToWideChar.  We have confirmed a guy from Microsoft who
said that

BEGIN QUOTE
I'm not sure how common it is to call the Java code that 
results in
calling the GetIfTable API but I would guess it does not 
happen that

often. Additionally, if it's rare that the adapter contains the
accented
characters, it would definitely be quite easy to miss in 
testing.


I have not found any documentation about the encoding of the 
bDescr

string unfortunately. I did, however, debug through the API and
located
the place where it is generated. It is getting converted from a
UTF-16
string to a single-byte string using a conversion like this:

WideCharToMultiByte(
CP_OEMCP,
WC_NO_BEST_FIT_CHARS,
,
-1,
IfRow->bDescr,
,
NULL,
NULL);

I have checked the source for Windows Vista, 2008, Windows 7, 
and
Windows 2008 R2. It is using CP_OEMCP in all of them. So 
using the

reverse conversion in your code using CP_OEMCP should be safe.
Alternatively, you can use the GetIfTable2 function
(http://msdn.microsoft.com/en-us/library/windows/desktop/aa365945^(v=vs.85).aspx 




) which returns the same information in the original UTF-16
encoding.
END QUOTE

 The link below may be helpful to the second param of
WideCharToMultiByte.
http://blogs.msdn.com/b/oldnewthing/archive/2012/05/04/10300670.aspx 



You comments are appreciated.
Best regards,
Frank