From chris.hegarty at oracle.com Sat Mar 1 09:42:23 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 1 Mar 2014 17:42:23 +0000 Subject: RFR [9] 8035897 : FD_SETSIZE should be set on macosx In-Reply-To: <20140301012749.C609917FDA0@rebar.astron.com> References: <20140301012749.C609917FDA0@rebar.astron.com> Message-ID: <2B393F8E-7E7A-4CAC-871A-9E1969BAEDA3@oracle.com> > On 1 Mar 2014, at 01:27, christos at zoulas.com wrote: > > On Feb 28, 5:41pm, chris.hegarty at oracle.com (Chris Hegarty) wrote: > -- Subject: Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx > > | We are using select on OS X, only, because of a bug in poll, see > | https://bugs.openjdk.java.net/browse/JDK-7131399 > | > | Michael ran into this in the original OpenJDK Mac port. > > Ouch! What did apple say about it? This is pretty bad, and they should fix it. I know that this has been reported to Apple, but I am not aware of the latest state of it. I'll try to follow up with them. -Chris > > christos From Alan.Bateman at oracle.com Sun Mar 2 02:53:33 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 02 Mar 2014 10:53:33 +0000 Subject: RFR [9] 8035868: Check for JNI pending exception in windows/native/sun/net/spi/DefaultProxySelector.c In-Reply-To: <84130CE3-2EB5-4B21-A12F-A4DABED33B55@oracle.com> References: <84130CE3-2EB5-4B21-A12F-A4DABED33B55@oracle.com> Message-ID: <53130DAD.3050908@oracle.com> On 28/02/2014 19:13, Chris Hegarty wrote: > Some more trivial checking in the Windows native code for JNI pending exceptions. > > http://cr.openjdk.java.net/~chegar/8035868/webrev.00/webrev/ > > -Chris. This looks okay to me. We should probably fix up the indentation of this code some time too. -Alan. From Alan.Bateman at oracle.com Sun Mar 2 11:44:14 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 02 Mar 2014 19:44:14 +0000 Subject: RFR [9] 8035897 : FD_SETSIZE should be set on macosx In-Reply-To: <53109FD7.5090103@oracle.com> References: <53109FD7.5090103@oracle.com> Message-ID: <53138A0E.5090506@oracle.com> On 28/02/2014 14:40, Chris Hegarty wrote: > : > > I think option 2 is preferable: > http://cr.openjdk.java.net/~chegar/8035897/webrev.00/webrev/ > > I'm still checking to see it an automatic regression test is possible, > but I wanted to circulate the changes for comment first. This mostly looks okay to me although it's a bit inconsistent for NET_Timeout to have a JNIEnv parameter. It might be better to have it set errno to ENOMEM or some error and handle it in the call instead. Also just on the exception message, I assume it should be "select" rather than NET_Select as NET_Select has been removed. As per the other comments then it would be good to re-visit the issue as to why select is used here as it would be good to replace it with poll if the issue with 0-length UDP packets has been fixed. -Alan. From ivan.gerasimov at oracle.com Mon Mar 3 08:32:16 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 03 Mar 2014 20:32:16 +0400 Subject: RFR: [8036088] - Thread-unsafe strtok() is used to parse the list of overrides Message-ID: <5314AE90.1070806@oracle.com> Hello! The strtok() function is used in ./windows/native/sun/net/spi/DefaultProxySelector.c. This function is not thread safe, so it may potentially cause a problem. The failure in this particular place would be very unlikely, because this code should be executed only once during initialization. Therefore, no regtest provided. The fix would be to use a thread-safe equivalent, which is strtok_s() under Windows. Would you please help review this simple fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8036088 WEBREV: http://cr.openjdk.java.net/~igerasim/8036088/0/webrev/ Sincerely yours, Ivan From chris.hegarty at oracle.com Mon Mar 3 08:45:52 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 03 Mar 2014 16:45:52 +0000 Subject: RFR [9] 8035897 : FD_SETSIZE should be set on macosx In-Reply-To: <53138A0E.5090506@oracle.com> References: <53109FD7.5090103@oracle.com> <53138A0E.5090506@oracle.com> Message-ID: <5314B1C0.5010904@oracle.com> Alan, I pushed this changes before receiving your comments. If you agree, I'll push the following changes under a new bug number. http://cr.openjdk.java.net/~chegar/8035897/webrev.comments/webrev/ The error handling seems a little overly complicated in PlainDatagramSocketImpl, but I don't proposed to change that in this issue. -Chris. On 02/03/14 19:44, Alan Bateman wrote: > On 28/02/2014 14:40, Chris Hegarty wrote: >> : >> >> I think option 2 is preferable: >> http://cr.openjdk.java.net/~chegar/8035897/webrev.00/webrev/ >> >> I'm still checking to see it an automatic regression test is possible, >> but I wanted to circulate the changes for comment first. > This mostly looks okay to me although it's a bit inconsistent for > NET_Timeout to have a JNIEnv parameter. It might be better to have it > set errno to ENOMEM or some error and handle it in the call instead. > Also just on the exception message, I assume it should be "select" > rather than NET_Select as NET_Select has been removed. > > As per the other comments then it would be good to re-visit the issue as > to why select is used here as it would be good to replace it with poll > if the issue with 0-length UDP packets has been fixed. > > -Alan. From Alan.Bateman at oracle.com Mon Mar 3 08:49:37 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 03 Mar 2014 16:49:37 +0000 Subject: RFR [9] 8035897 : FD_SETSIZE should be set on macosx In-Reply-To: <5314B1C0.5010904@oracle.com> References: <53109FD7.5090103@oracle.com> <53138A0E.5090506@oracle.com> <5314B1C0.5010904@oracle.com> Message-ID: <5314B2A1.2060709@oracle.com> On 03/03/2014 16:45, Chris Hegarty wrote: > Alan, > > I pushed this changes before receiving your comments. If you agree, > I'll push the following changes under a new bug number. > > http://cr.openjdk.java.net/~chegar/8035897/webrev.comments/webrev/ > > The error handling seems a little overly complicated in > PlainDatagramSocketImpl, but I don't proposed to change that in this > issue. > > -Chris. Thanks for taking the comment on board, this looks good. -Alan From christos at zoulas.com Mon Mar 3 08:52:46 2014 From: christos at zoulas.com (Christos Zoulas) Date: Mon, 3 Mar 2014 11:52:46 -0500 Subject: RFR: [8036088] - Thread-unsafe strtok() is used to parse the list of overrides In-Reply-To: <5314AE90.1070806@oracle.com> from Ivan Gerasimov (Mar 3, 8:32pm) Message-ID: <20140303165246.6135417FDA0@rebar.astron.com> On Mar 3, 8:32pm, ivan.gerasimov at oracle.com (Ivan Gerasimov) wrote: -- Subject: RFR: [8036088] - Thread-unsafe strtok() is used to parse the list | Hello! | | The strtok() function is used in | ./windows/native/sun/net/spi/DefaultProxySelector.c. | This function is not thread safe, so it may potentially cause a problem. | | The failure in this particular place would be very unlikely, because | this code should be executed only once during initialization. | Therefore, no regtest provided. | | The fix would be to use a thread-safe equivalent, which is strtok_s() | under Windows. | | Would you please help review this simple fix? | | BUGURL: https://bugs.openjdk.java.net/browse/JDK-8036088 | WEBREV: http://cr.openjdk.java.net/~igerasim/8036088/0/webrev/ Doesn't windows have strtok_r() IEEE Std 1003.1c-1995 (``POSIX.1''). christos From ivan.gerasimov at oracle.com Mon Mar 3 09:01:15 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 03 Mar 2014 21:01:15 +0400 Subject: RFR: [8036088] - Thread-unsafe strtok() is used to parse the list of overrides In-Reply-To: <20140303165246.6135417FDA0@rebar.astron.com> References: <20140303165246.6135417FDA0@rebar.astron.com> Message-ID: <5314B55B.9070406@oracle.com> Hi Christos! On 03.03.2014 20:52, christos at zoulas.com wrote: > On Mar 3, 8:32pm, ivan.gerasimov at oracle.com (Ivan Gerasimov) wrote: > -- Subject: RFR: [8036088] - Thread-unsafe strtok() is used to parse the list > > | Hello! > | > | The strtok() function is used in > | ./windows/native/sun/net/spi/DefaultProxySelector.c. > | This function is not thread safe, so it may potentially cause a problem. > | > | The failure in this particular place would be very unlikely, because > | this code should be executed only once during initialization. > | Therefore, no regtest provided. > | > | The fix would be to use a thread-safe equivalent, which is strtok_s() > | under Windows. > | > | Would you please help review this simple fix? > | > | BUGURL: https://bugs.openjdk.java.net/browse/JDK-8036088 > | WEBREV: http://cr.openjdk.java.net/~igerasim/8036088/0/webrev/ > > Doesn't windows have strtok_r() IEEE Std 1003.1c-1995 (``POSIX.1''). MSDN does not refer to strtok_r(). Grepping the JDK code shows that strtok_s() is used in the windows-specific code. Sincerely yours, Ivan > christos > > From Thomas.Salter at unisys.com Mon Mar 3 12:26:01 2014 From: Thomas.Salter at unisys.com (Salter, Thomas A) Date: Mon, 3 Mar 2014 14:26:01 -0600 Subject: RFR: [8036088] - Thread-unsafe strtok() is used to parse In-Reply-To: References: Message-ID: <63D5DCACD1E9E34C89C8203C64F521C301491D8DF686@USEA-EXCH7.na.uis.unisys.com> strtok is thread-safe in MS C/C++. It uses thread-local store to hold its state. strtok_s can be called recursively to parse different strings, though it's named like the MS extensions that check for buffer overruns. http://msdn.microsoft.com/en-us/library/2c8d19sb(v=vs.100).aspx ------------------------------ Message: 5 Date: Mon, 03 Mar 2014 21:01:15 +0400 From: Ivan Gerasimov Subject: Re: RFR: [8036088] - Thread-unsafe strtok() is used to parse the list of overrides To: Christos Zoulas , OpenJDK Network Dev list Message-ID: <5314B55B.9070406 at oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Hi Christos! On 03.03.2014 20:52, christos at zoulas.com wrote: > On Mar 3, 8:32pm, ivan.gerasimov at oracle.com (Ivan Gerasimov) wrote: > -- Subject: RFR: [8036088] - Thread-unsafe strtok() is used to parse the list > > | Hello! > | > | The strtok() function is used in > | ./windows/native/sun/net/spi/DefaultProxySelector.c. > | This function is not thread safe, so it may potentially cause a problem. > | > | The failure in this particular place would be very unlikely, because > | this code should be executed only once during initialization. > | Therefore, no regtest provided. > | > | The fix would be to use a thread-safe equivalent, which is strtok_s() > | under Windows. > | > | Would you please help review this simple fix? > | > | BUGURL: https://bugs.openjdk.java.net/browse/JDK-8036088 > | WEBREV: http://cr.openjdk.java.net/~igerasim/8036088/0/webrev/ > > Doesn't windows have strtok_r() IEEE Std 1003.1c-1995 (``POSIX.1''). MSDN does not refer to strtok_r(). Grepping the JDK code shows that strtok_s() is used in the windows-specific code. Sincerely yours, Ivan > christos > > End of net-dev Digest, Vol 81, Issue 3 ************************************** From ivan.gerasimov at oracle.com Mon Mar 3 19:25:00 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 04 Mar 2014 07:25:00 +0400 Subject: RFR: [8036088] - Thread-unsafe strtok() is used to parse In-Reply-To: <63D5DCACD1E9E34C89C8203C64F521C301491D8DF686@USEA-EXCH7.na.uis.unisys.com> References: <63D5DCACD1E9E34C89C8203C64F521C301491D8DF686@USEA-EXCH7.na.uis.unisys.com> Message-ID: <5315478C.408@oracle.com> Yes, you're right. strtok() is thread-safe in Windows unlike its Unix counterpart. Thus using strtok_s() only adds some boundary checking in this case. Sincerely yours, Ivan On 04.03.2014 0:26, Salter, Thomas A wrote: > strtok is thread-safe in MS C/C++. It uses thread-local store to hold its state. strtok_s can be called recursively to parse different strings, though it's named like the MS extensions that check for buffer overruns. > > http://msdn.microsoft.com/en-us/library/2c8d19sb(v=vs.100).aspx > > ------------------------------ > > Message: 5 > Date: Mon, 03 Mar 2014 21:01:15 +0400 > From: Ivan Gerasimov > Subject: Re: RFR: [8036088] - Thread-unsafe strtok() is used to parse > the list of overrides > To: Christos Zoulas , OpenJDK Network Dev list > > Message-ID: <5314B55B.9070406 at oracle.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi Christos! > > On 03.03.2014 20:52, christos at zoulas.com wrote: >> On Mar 3, 8:32pm, ivan.gerasimov at oracle.com (Ivan Gerasimov) wrote: >> -- Subject: RFR: [8036088] - Thread-unsafe strtok() is used to parse the list >> >> | Hello! >> | >> | The strtok() function is used in >> | ./windows/native/sun/net/spi/DefaultProxySelector.c. >> | This function is not thread safe, so it may potentially cause a problem. >> | >> | The failure in this particular place would be very unlikely, because >> | this code should be executed only once during initialization. >> | Therefore, no regtest provided. >> | >> | The fix would be to use a thread-safe equivalent, which is strtok_s() >> | under Windows. >> | >> | Would you please help review this simple fix? >> | >> | BUGURL: https://bugs.openjdk.java.net/browse/JDK-8036088 >> | WEBREV: http://cr.openjdk.java.net/~igerasim/8036088/0/webrev/ >> >> Doesn't windows have strtok_r() IEEE Std 1003.1c-1995 (``POSIX.1''). > MSDN does not refer to strtok_r(). > Grepping the JDK code shows that strtok_s() is used in the > windows-specific code. > > Sincerely yours, > Ivan > >> christos >> >> > > > End of net-dev Digest, Vol 81, Issue 3 > ************************************** > > From chris.hegarty at oracle.com Tue Mar 4 02:28:39 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 4 Mar 2014 10:28:39 +0000 Subject: RFR: [8036088] - Thread-unsafe strtok() is used to parse In-Reply-To: <5315478C.408@oracle.com> References: <63D5DCACD1E9E34C89C8203C64F521C301491D8DF686@USEA-EXCH7.na.uis.unisys.com> <5315478C.408@oracle.com> Message-ID: <71338B7D-9CB9-4361-AD3B-ECE3ABACB851@oracle.com> On 4 Mar 2014, at 03:25, Ivan Gerasimov wrote: > Yes, you're right. > strtok() is thread-safe in Windows unlike its Unix counterpart. > > Thus using strtok_s() only adds some boundary checking in this case. Ivan, Are you now withdrawing this request for review? Or are you suggesting that strtok_s should be used anyway? -Chris. > > Sincerely yours, > Ivan > > On 04.03.2014 0:26, Salter, Thomas A wrote: >> strtok is thread-safe in MS C/C++. It uses thread-local store to hold its state. strtok_s can be called recursively to parse different strings, though it's named like the MS extensions that check for buffer overruns. >> >> http://msdn.microsoft.com/en-us/library/2c8d19sb(v=vs.100).aspx >> >> ------------------------------ >> >> Message: 5 >> Date: Mon, 03 Mar 2014 21:01:15 +0400 >> From: Ivan Gerasimov >> Subject: Re: RFR: [8036088] - Thread-unsafe strtok() is used to parse >> the list of overrides >> To: Christos Zoulas , OpenJDK Network Dev list >> >> Message-ID: <5314B55B.9070406 at oracle.com> >> Content-Type: text/plain; charset=UTF-8; format=flowed >> >> Hi Christos! >> >> On 03.03.2014 20:52, christos at zoulas.com wrote: >>> On Mar 3, 8:32pm, ivan.gerasimov at oracle.com (Ivan Gerasimov) wrote: >>> -- Subject: RFR: [8036088] - Thread-unsafe strtok() is used to parse the list >>> >>> | Hello! >>> | >>> | The strtok() function is used in >>> | ./windows/native/sun/net/spi/DefaultProxySelector.c. >>> | This function is not thread safe, so it may potentially cause a problem. >>> | >>> | The failure in this particular place would be very unlikely, because >>> | this code should be executed only once during initialization. >>> | Therefore, no regtest provided. >>> | >>> | The fix would be to use a thread-safe equivalent, which is strtok_s() >>> | under Windows. >>> | >>> | Would you please help review this simple fix? >>> | >>> | BUGURL: https://bugs.openjdk.java.net/browse/JDK-8036088 >>> | WEBREV: http://cr.openjdk.java.net/~igerasim/8036088/0/webrev/ >>> >>> Doesn't windows have strtok_r() IEEE Std 1003.1c-1995 (``POSIX.1''). >> MSDN does not refer to strtok_r(). >> Grepping the JDK code shows that strtok_s() is used in the >> windows-specific code. >> >> Sincerely yours, >> Ivan >> >>> christos >>> >>> >> >> >> End of net-dev Digest, Vol 81, Issue 3 >> ************************************** >> >> > From mark.sheppard at oracle.com Tue Mar 4 03:06:46 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Tue, 04 Mar 2014 11:06:46 +0000 Subject: RFR: 8025293 - JNI exception pending checks in java.net Message-ID: <5315B3C6.9050004@oracle.com> Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8025293/webrev/ to address the issue in https://bugs.openjdk.java.net/browse/JDK-8025293 this applies additional checks after JNI native calls in src/solaris/native/java/net/NetworkInterface.c src/windows/native/java/net/NetworkInterface.c The main changes are NULL checks and pending exception checks. regards Mark From Alan.Bateman at oracle.com Tue Mar 4 03:28:00 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 04 Mar 2014 11:28:00 +0000 Subject: RFR: 8025293 - JNI exception pending checks in java.net In-Reply-To: <5315B3C6.9050004@oracle.com> References: <5315B3C6.9050004@oracle.com> Message-ID: <5315B8C0.30500@oracle.com> On 04/03/2014 11:06, Mark Sheppard wrote: > Hi > please oblige and review the following changes > > http://cr.openjdk.java.net/~msheppar/8025293/webrev/ > > to address the issue in > > https://bugs.openjdk.java.net/browse/JDK-8025293 > > this applies additional checks after JNI native calls in > src/solaris/native/java/net/NetworkInterface.c > src/windows/native/java/net/NetworkInterface.c > > The main changes are NULL checks and pending exception checks. I went through the webrev and it looks reasonable to me. The awkwardness of not knowing if GetStringUTFChars fails with a pending exception or not makes me wonder if the recent suggestion on core-libs-dev to check for a pending exception might be worth looking at again, even by introducing variations of JNU_ThrowOutOfMemoryError. Not for this patch of course but this patch does highlight the issue again. One thing that isn't 100% clear to me is in the Solaris/Linux version of addif where it returns ifs if either getBroadcast or getSubnet fail with a pending exception. Is there additional cleanup/free that needs to be done for this case or is this the reason for returning the partially initialized ifs. I also wonder if it's necessary to check for a pending exception, could getBroadcast returning NULL is used too? -Alan. From chris.hegarty at oracle.com Tue Mar 4 03:27:51 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 4 Mar 2014 11:27:51 +0000 Subject: RFR: 8025293 - JNI exception pending checks in java.net In-Reply-To: <5315B3C6.9050004@oracle.com> References: <5315B3C6.9050004@oracle.com> Message-ID: This looks good to me Mark. Trivially, and it is more of a stylistic preference, towards the end of the Solaris NetworkInterface.c I would remove the if (ob) ? else, and use CHECK_NULL_RETURN(obj, NULL). But, what you have is right, either is fine. -Chris. On 4 Mar 2014, at 11:06, Mark Sheppard wrote: > Hi > please oblige and review the following changes > > http://cr.openjdk.java.net/~msheppar/8025293/webrev/ > > to address the issue in > > https://bugs.openjdk.java.net/browse/JDK-8025293 > > this applies additional checks after JNI native calls in > src/solaris/native/java/net/NetworkInterface.c > src/windows/native/java/net/NetworkInterface.c > > The main changes are NULL checks and pending exception checks. > > regards > Mark From mark.sheppard at oracle.com Tue Mar 4 03:41:39 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Tue, 04 Mar 2014 11:41:39 +0000 Subject: RFR: 8025293 - JNI exception pending checks in java.net In-Reply-To: References: <5315B3C6.9050004@oracle.com> Message-ID: <5315BBF3.5090005@oracle.com> Chris, thanks for the response. I can use the common CHECK_NULL_RETURN convention if preferred. The reason I went with if ( name_utf != NULL) { ...} else { ...} is because the != NULL is the most likely code path in getByName. Nonetheless, I'll make the change for consistency. regards Mark On 04/03/2014 11:27, Chris Hegarty wrote: > This looks good to me Mark. > > Trivially, and it is more of a stylistic preference, towards the end of the Solaris NetworkInterface.c I would remove the if (ob) ? else, and use CHECK_NULL_RETURN(obj, NULL). But, what you have is right, either is fine. > > -Chris. > > On 4 Mar 2014, at 11:06, Mark Sheppard wrote: > >> Hi >> please oblige and review the following changes >> >> http://cr.openjdk.java.net/~msheppar/8025293/webrev/ >> >> to address the issue in >> >> https://bugs.openjdk.java.net/browse/JDK-8025293 >> >> this applies additional checks after JNI native calls in >> src/solaris/native/java/net/NetworkInterface.c >> src/windows/native/java/net/NetworkInterface.c >> >> The main changes are NULL checks and pending exception checks. >> >> regards >> Mark From ivan.gerasimov at oracle.com Tue Mar 4 03:52:41 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 04 Mar 2014 15:52:41 +0400 Subject: RFR: [8036088] - Thread-unsafe strtok() is used to parse In-Reply-To: <71338B7D-9CB9-4361-AD3B-ECE3ABACB851@oracle.com> References: <63D5DCACD1E9E34C89C8203C64F521C301491D8DF686@USEA-EXCH7.na.uis.unisys.com> <5315478C.408@oracle.com> <71338B7D-9CB9-4361-AD3B-ECE3ABACB851@oracle.com> Message-ID: <5315BE89.3030302@oracle.com> VS compiler issues this warning on strtok() usage: : warning C4996: 'strtok': This function or variable may be unsafe. Consider using strtok_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. So, the suggested fix can reduce number of complains from the compiler. If I had realized that strtok() is thread-safe under Windows, I wouldn't bother anyone with this. But as the fix is already prepared, I think it's better push it, even though it adds only a little. If you guys are OK with the fix, of course. Sincerely yours, Ivan On 04.03.2014 14:28, Chris Hegarty wrote: > On 4 Mar 2014, at 03:25, Ivan Gerasimov wrote: > >> Yes, you're right. >> strtok() is thread-safe in Windows unlike its Unix counterpart. >> >> Thus using strtok_s() only adds some boundary checking in this case. > Ivan, > Are you now withdrawing this request for review? Or are you suggesting that strtok_s should be used anyway? > > -Chris. > >> Sincerely yours, >> Ivan >> >> On 04.03.2014 0:26, Salter, Thomas A wrote: >>> strtok is thread-safe in MS C/C++. It uses thread-local store to hold its state. strtok_s can be called recursively to parse different strings, though it's named like the MS extensions that check for buffer overruns. >>> >>> http://msdn.microsoft.com/en-us/library/2c8d19sb(v=vs.100).aspx >>> >>> ------------------------------ >>> >>> Message: 5 >>> Date: Mon, 03 Mar 2014 21:01:15 +0400 >>> From: Ivan Gerasimov >>> Subject: Re: RFR: [8036088] - Thread-unsafe strtok() is used to parse >>> the list of overrides >>> To: Christos Zoulas , OpenJDK Network Dev list >>> >>> Message-ID: <5314B55B.9070406 at oracle.com> >>> Content-Type: text/plain; charset=UTF-8; format=flowed >>> >>> Hi Christos! >>> >>> On 03.03.2014 20:52, christos at zoulas.com wrote: >>>> On Mar 3, 8:32pm, ivan.gerasimov at oracle.com (Ivan Gerasimov) wrote: >>>> -- Subject: RFR: [8036088] - Thread-unsafe strtok() is used to parse the list >>>> >>>> | Hello! >>>> | >>>> | The strtok() function is used in >>>> | ./windows/native/sun/net/spi/DefaultProxySelector.c. >>>> | This function is not thread safe, so it may potentially cause a problem. >>>> | >>>> | The failure in this particular place would be very unlikely, because >>>> | this code should be executed only once during initialization. >>>> | Therefore, no regtest provided. >>>> | >>>> | The fix would be to use a thread-safe equivalent, which is strtok_s() >>>> | under Windows. >>>> | >>>> | Would you please help review this simple fix? >>>> | >>>> | BUGURL: https://bugs.openjdk.java.net/browse/JDK-8036088 >>>> | WEBREV: http://cr.openjdk.java.net/~igerasim/8036088/0/webrev/ >>>> >>>> Doesn't windows have strtok_r() IEEE Std 1003.1c-1995 (``POSIX.1''). >>> MSDN does not refer to strtok_r(). >>> Grepping the JDK code shows that strtok_s() is used in the >>> windows-specific code. >>> >>> Sincerely yours, >>> Ivan >>> >>>> christos >>>> >>>> >>> >>> End of net-dev Digest, Vol 81, Issue 3 >>> ************************************** >>> >>> > > From mark.sheppard at oracle.com Tue Mar 4 03:54:33 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Tue, 04 Mar 2014 11:54:33 +0000 Subject: RFR: 8025293 - JNI exception pending checks in java.net In-Reply-To: <5315B8C0.30500@oracle.com> References: <5315B3C6.9050004@oracle.com> <5315B8C0.30500@oracle.com> Message-ID: <5315BEF9.6020805@oracle.com> Hi Alan, thanks for the response. I originally had a CHECK_NULL_RETURN after getBraodcast and tests failed on Macos, but not on other platforms! The issue is that getBroadcast returns NULL when broadcast is not available for an interface, or when the ioctl calls return an error. The former is the case on macos with the loopback lo interface. Hence we went with the ExceptionCheck after these calls. WRT returning ifs, I just followed the convention created in the CHECKED_MALLOC3 macro, as ifs is an "in" parameter. regards Mark On 04/03/2014 11:28, Alan Bateman wrote: > On 04/03/2014 11:06, Mark Sheppard wrote: >> Hi >> please oblige and review the following changes >> >> http://cr.openjdk.java.net/~msheppar/8025293/webrev/ >> >> to address the issue in >> >> https://bugs.openjdk.java.net/browse/JDK-8025293 >> >> this applies additional checks after JNI native calls in >> src/solaris/native/java/net/NetworkInterface.c >> src/windows/native/java/net/NetworkInterface.c >> >> The main changes are NULL checks and pending exception checks. > I went through the webrev and it looks reasonable to me. The > awkwardness of not knowing if GetStringUTFChars fails with a pending > exception or not makes me wonder if the recent suggestion on > core-libs-dev to check for a pending exception might be worth looking > at again, even by introducing variations of JNU_ThrowOutOfMemoryError. > Not for this patch of course but this patch does highlight the issue > again. > > One thing that isn't 100% clear to me is in the Solaris/Linux version > of addif where it returns ifs if either getBroadcast or getSubnet fail > with a pending exception. Is there additional cleanup/free that needs > to be done for this case or is this the reason for returning the > partially initialized ifs. I also wonder if it's necessary to check > for a pending exception, could getBroadcast returning NULL is used too? > > -Alan. > > From chris.hegarty at oracle.com Tue Mar 4 04:43:44 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 4 Mar 2014 12:43:44 +0000 Subject: RFR: [8036088] - Thread-unsafe strtok() is used to parse In-Reply-To: <5315BE89.3030302@oracle.com> References: <63D5DCACD1E9E34C89C8203C64F521C301491D8DF686@USEA-EXCH7.na.uis.unisys.com> <5315478C.408@oracle.com> <71338B7D-9CB9-4361-AD3B-ECE3ABACB851@oracle.com> <5315BE89.3030302@oracle.com> Message-ID: <7FCCF50E-CDC7-4CB2-9833-3578E711D8C7@oracle.com> On 4 Mar 2014, at 11:52, Ivan Gerasimov wrote: > VS compiler issues this warning on strtok() usage: > > : warning C4996: 'strtok': This function or variable may be unsafe. Consider using strtok_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. > > So, the suggested fix can reduce number of complains from the compiler. > > If I had realized that strtok() is thread-safe under Windows, I wouldn't bother anyone with this. > But as the fix is already prepared, I think it's better push it, even though it adds only a little. > If you guys are OK with the fix, of course. The changes seem mostly benign to me. I have no objections to being listed as a reviewer. -Chris. > > Sincerely yours, > Ivan > > > On 04.03.2014 14:28, Chris Hegarty wrote: >> On 4 Mar 2014, at 03:25, Ivan Gerasimov wrote: >> >>> Yes, you're right. >>> strtok() is thread-safe in Windows unlike its Unix counterpart. >>> >>> Thus using strtok_s() only adds some boundary checking in this case. >> Ivan, >> Are you now withdrawing this request for review? Or are you suggesting that strtok_s should be used anyway? >> >> -Chris. >> >>> Sincerely yours, >>> Ivan >>> >>> On 04.03.2014 0:26, Salter, Thomas A wrote: >>>> strtok is thread-safe in MS C/C++. It uses thread-local store to hold its state. strtok_s can be called recursively to parse different strings, though it's named like the MS extensions that check for buffer overruns. >>>> >>>> http://msdn.microsoft.com/en-us/library/2c8d19sb(v=vs.100).aspx >>>> >>>> ------------------------------ >>>> >>>> Message: 5 >>>> Date: Mon, 03 Mar 2014 21:01:15 +0400 >>>> From: Ivan Gerasimov >>>> Subject: Re: RFR: [8036088] - Thread-unsafe strtok() is used to parse >>>> the list of overrides >>>> To: Christos Zoulas , OpenJDK Network Dev list >>>> >>>> Message-ID: <5314B55B.9070406 at oracle.com> >>>> Content-Type: text/plain; charset=UTF-8; format=flowed >>>> >>>> Hi Christos! >>>> >>>> On 03.03.2014 20:52, christos at zoulas.com wrote: >>>>> On Mar 3, 8:32pm, ivan.gerasimov at oracle.com (Ivan Gerasimov) wrote: >>>>> -- Subject: RFR: [8036088] - Thread-unsafe strtok() is used to parse the list >>>>> >>>>> | Hello! >>>>> | >>>>> | The strtok() function is used in >>>>> | ./windows/native/sun/net/spi/DefaultProxySelector.c. >>>>> | This function is not thread safe, so it may potentially cause a problem. >>>>> | >>>>> | The failure in this particular place would be very unlikely, because >>>>> | this code should be executed only once during initialization. >>>>> | Therefore, no regtest provided. >>>>> | >>>>> | The fix would be to use a thread-safe equivalent, which is strtok_s() >>>>> | under Windows. >>>>> | >>>>> | Would you please help review this simple fix? >>>>> | >>>>> | BUGURL: https://bugs.openjdk.java.net/browse/JDK-8036088 >>>>> | WEBREV: http://cr.openjdk.java.net/~igerasim/8036088/0/webrev/ >>>>> >>>>> Doesn't windows have strtok_r() IEEE Std 1003.1c-1995 (``POSIX.1''). >>>> MSDN does not refer to strtok_r(). >>>> Grepping the JDK code shows that strtok_s() is used in the >>>> windows-specific code. >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>>> christos >>>>> >>>>> >>>> >>>> End of net-dev Digest, Vol 81, Issue 3 >>>> ************************************** >>>> >>>> >> >> > From ivan.gerasimov at oracle.com Tue Mar 4 04:51:13 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 04 Mar 2014 16:51:13 +0400 Subject: RFR: [8036088] - Thread-unsafe strtok() is used to parse In-Reply-To: <7FCCF50E-CDC7-4CB2-9833-3578E711D8C7@oracle.com> References: <63D5DCACD1E9E34C89C8203C64F521C301491D8DF686@USEA-EXCH7.na.uis.unisys.com> <5315478C.408@oracle.com> <71338B7D-9CB9-4361-AD3B-ECE3ABACB851@oracle.com> <5315BE89.3030302@oracle.com> <7FCCF50E-CDC7-4CB2-9833-3578E711D8C7@oracle.com> Message-ID: <5315CC41.1050903@oracle.com> Thank you Chris! On 04.03.2014 16:43, Chris Hegarty wrote: > On 4 Mar 2014, at 11:52, Ivan Gerasimov wrote: > >> VS compiler issues this warning on strtok() usage: >> >> : warning C4996: 'strtok': This function or variable may be unsafe. Consider using strtok_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. >> >> So, the suggested fix can reduce number of complains from the compiler. >> >> If I had realized that strtok() is thread-safe under Windows, I wouldn't bother anyone with this. >> But as the fix is already prepared, I think it's better push it, even though it adds only a little. >> If you guys are OK with the fix, of course. > The changes seem mostly benign to me. I have no objections to being listed as a reviewer. > > -Chris. > >> Sincerely yours, >> Ivan >> >> >> On 04.03.2014 14:28, Chris Hegarty wrote: >>> On 4 Mar 2014, at 03:25, Ivan Gerasimov wrote: >>> >>>> Yes, you're right. >>>> strtok() is thread-safe in Windows unlike its Unix counterpart. >>>> >>>> Thus using strtok_s() only adds some boundary checking in this case. >>> Ivan, >>> Are you now withdrawing this request for review? Or are you suggesting that strtok_s should be used anyway? >>> >>> -Chris. >>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> On 04.03.2014 0:26, Salter, Thomas A wrote: >>>>> strtok is thread-safe in MS C/C++. It uses thread-local store to hold its state. strtok_s can be called recursively to parse different strings, though it's named like the MS extensions that check for buffer overruns. >>>>> >>>>> http://msdn.microsoft.com/en-us/library/2c8d19sb(v=vs.100).aspx >>>>> >>>>> ------------------------------ >>>>> >>>>> Message: 5 >>>>> Date: Mon, 03 Mar 2014 21:01:15 +0400 >>>>> From: Ivan Gerasimov >>>>> Subject: Re: RFR: [8036088] - Thread-unsafe strtok() is used to parse >>>>> the list of overrides >>>>> To: Christos Zoulas , OpenJDK Network Dev list >>>>> >>>>> Message-ID: <5314B55B.9070406 at oracle.com> >>>>> Content-Type: text/plain; charset=UTF-8; format=flowed >>>>> >>>>> Hi Christos! >>>>> >>>>> On 03.03.2014 20:52, christos at zoulas.com wrote: >>>>>> On Mar 3, 8:32pm, ivan.gerasimov at oracle.com (Ivan Gerasimov) wrote: >>>>>> -- Subject: RFR: [8036088] - Thread-unsafe strtok() is used to parse the list >>>>>> >>>>>> | Hello! >>>>>> | >>>>>> | The strtok() function is used in >>>>>> | ./windows/native/sun/net/spi/DefaultProxySelector.c. >>>>>> | This function is not thread safe, so it may potentially cause a problem. >>>>>> | >>>>>> | The failure in this particular place would be very unlikely, because >>>>>> | this code should be executed only once during initialization. >>>>>> | Therefore, no regtest provided. >>>>>> | >>>>>> | The fix would be to use a thread-safe equivalent, which is strtok_s() >>>>>> | under Windows. >>>>>> | >>>>>> | Would you please help review this simple fix? >>>>>> | >>>>>> | BUGURL: https://bugs.openjdk.java.net/browse/JDK-8036088 >>>>>> | WEBREV: http://cr.openjdk.java.net/~igerasim/8036088/0/webrev/ >>>>>> >>>>>> Doesn't windows have strtok_r() IEEE Std 1003.1c-1995 (``POSIX.1''). >>>>> MSDN does not refer to strtok_r(). >>>>> Grepping the JDK code shows that strtok_s() is used in the >>>>> windows-specific code. >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>>> christos >>>>>> >>>>>> >>>>> End of net-dev Digest, Vol 81, Issue 3 >>>>> ************************************** >>>>> >>>>> >>> > > From Alan.Bateman at oracle.com Tue Mar 4 05:17:31 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 04 Mar 2014 13:17:31 +0000 Subject: RFR: 8025293 - JNI exception pending checks in java.net In-Reply-To: <5315BEF9.6020805@oracle.com> References: <5315B3C6.9050004@oracle.com> <5315B8C0.30500@oracle.com> <5315BEF9.6020805@oracle.com> Message-ID: <5315D26B.5090704@oracle.com> On 04/03/2014 11:54, Mark Sheppard wrote: > Hi Alan, > thanks for the response. I originally had a CHECK_NULL_RETURN after > getBraodcast and tests > failed on Macos, but not on other platforms! > The issue is that getBroadcast returns NULL when broadcast is not > available for an interface, or when the ioctl calls > return an error. Thanks, I missed the fact that it also returns NULL when there isn't a broadcast address. > The former is the case on macos with the loopback lo interface. > Hence we went with the ExceptionCheck after these calls. > WRT returning ifs, I just followed the convention created in the > CHECKED_MALLOC3 macro, as > ifs is an "in" parameter. Got it, it just means that each addif usage needs to check for a JNI exception and that seems to be the case. -Alan. From yiming.wang at oracle.com Wed Mar 5 01:48:46 2014 From: yiming.wang at oracle.com (Eric Wang) Date: Wed, 05 Mar 2014 17:48:46 +0800 Subject: RFR for bug JDK-8025209 Intermittent test failure: java/net/Socket/asyncClose/AsyncClose.java Message-ID: <5316F2FE.5040501@oracle.com> Hi everyone, Hi Everyone, I'm working on the test bug https://bugs.openjdk.java.net/browse/JDK-8025209, The test uses Thread.sleep to sync-up threads which is not a correct assumption. The fix is just to sync-up 2 threads using proper way. The webrev will be sent after internal review. Please let me know if you have any comment. Thanks, Eric From chris.hegarty at oracle.com Wed Mar 5 02:01:27 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 5 Mar 2014 10:01:27 +0000 Subject: RFR for bug JDK-8025209 Intermittent test failure: java/net/Socket/asyncClose/AsyncClose.java In-Reply-To: <5316F2FE.5040501@oracle.com> References: <5316F2FE.5040501@oracle.com> Message-ID: On 5 Mar 2014, at 09:48, Eric Wang wrote: > Hi everyone, > > Hi Everyone, > > I'm working on the test bug https://bugs.openjdk.java.net/browse/JDK-8025209, The test uses Thread.sleep to sync-up threads which is not a correct assumption. The fix is just to sync-up 2 threads using proper way. > > The webrev will be sent after internal review. Please let me know if you have any comment. This test is part of the OpenJDK source. Please just post your webrev externally for review. Thanks, -Chris. > > Thanks, > Eric > From mark.sheppard at oracle.com Fri Mar 7 03:46:55 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Fri, 07 Mar 2014 11:46:55 +0000 Subject: RFR: JDK-8036607 - JNI exception pending in jdk/src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c Message-ID: <5319B1AF.4090408@oracle.com> Hi Please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8036607/webrev/ which address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8036607 Summary: Changes to src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c two additions to take into account pending JNI exceptions have been added regards Mark -----------------------------------------------------------------oOo------------------------------------------------------------------------------------- diff -r 9099a251d211 src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c --- a/src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c Wed Mar 05 11:53:35 2014 -0800 +++ b/src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c Fri Mar 07 11:44:51 2014 +0000 @@ -384,15 +384,19 @@ JNIEXPORT jint JNICALL Java_java_net_Dua if (packetAddress == NULL) { packetAddress = NET_SockaddrToInetAddress(env, (struct sockaddr *)&sa, &port); - /* stuff the new Inetaddress into the packet */ - (*env)->SetObjectField(env, dpObj, dp_addressID, packetAddress); + if (packetAddress != NULL) { + /* stuff the new Inetaddress into the packet */ + (*env)->SetObjectField(env, dpObj, dp_addressID, packetAddress); + } } - /* populate the packet */ - (*env)->SetByteArrayRegion(env, packetBuffer, packetBufferOffset, rv, + if (!(*env)->ExceptionCheck(env)) { + /* populate the packet */ + (*env)->SetByteArrayRegion(env, packetBuffer, packetBufferOffset, rv, (jbyte *)fullPacket); - (*env)->SetIntField(env, dpObj, dp_portID, port); - (*env)->SetIntField(env, dpObj, dp_lengthID, rv); + (*env)->SetIntField(env, dpObj, dp_portID, port); + (*env)->SetIntField(env, dpObj, dp_lengthID, rv); + } } if (packetBufferLen > MAX_BUFFER_LEN) { From Alan.Bateman at oracle.com Fri Mar 7 03:53:35 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 07 Mar 2014 11:53:35 +0000 Subject: RFR: JDK-8036607 - JNI exception pending in jdk/src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c In-Reply-To: <5319B1AF.4090408@oracle.com> References: <5319B1AF.4090408@oracle.com> Message-ID: <5319B33F.5030604@oracle.com> On 07/03/2014 11:46, Mark Sheppard wrote: > Hi > Please oblige and review the following changes > http://cr.openjdk.java.net/~msheppar/8036607/webrev/ > > which address the issue raised in > https://bugs.openjdk.java.net/browse/JDK-8036607 This looks okay to me. A slightly more efficient alternative would be to just check again if packetAddress is NULL. -Alan. From mark.sheppard at oracle.com Wed Mar 12 16:43:08 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 12 Mar 2014 16:43:08 +0000 Subject: RFR: JDK8036601 - NI exception pending in jdk/src/windows/native/sun/net/dns/ResolverConfigurationImpl.c Message-ID: <53208E9C.4080507@oracle.com> Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8036601/webrev/ which address the issues raised in https://bugs.openjdk.java.net/browse/JDK-8036601 summary: NULL return value checks and JNU_ThrowOutOfMemoryError added regards Mark From Alan.Bateman at oracle.com Wed Mar 12 16:51:50 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Mar 2014 16:51:50 +0000 Subject: RFR: JDK8036601 - NI exception pending in jdk/src/windows/native/sun/net/dns/ResolverConfigurationImpl.c In-Reply-To: <53208E9C.4080507@oracle.com> References: <53208E9C.4080507@oracle.com> Message-ID: <532090A6.4010000@oracle.com> On 12/03/2014 16:43, Mark Sheppard wrote: > Hi > please oblige and review the following changes > http://cr.openjdk.java.net/~msheppar/8036601/webrev/ This mostly looks good to me. One observation is that is the return from loadConfig isn't clear. What would you think about adding STS_ERROR (-1) so that it's clear from loadConfig and the caller that this is the error case. In the original code there ere several status values and the IS_XXX macros were used to check them. -Alan. From mark.sheppard at oracle.com Wed Mar 12 17:02:30 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 12 Mar 2014 17:02:30 +0000 Subject: RFR: JDK8036601 - NI exception pending in jdk/src/windows/native/sun/net/dns/ResolverConfigurationImpl.c In-Reply-To: <532090A6.4010000@oracle.com> References: <53208E9C.4080507@oracle.com> <532090A6.4010000@oracle.com> Message-ID: <53209326.1070901@oracle.com> Hi Alan, thanks for the reply .... yes, I'll add the STS_ERROR regards Mark On 12/03/2014 16:51, Alan Bateman wrote: > On 12/03/2014 16:43, Mark Sheppard wrote: >> Hi >> please oblige and review the following changes >> http://cr.openjdk.java.net/~msheppar/8036601/webrev/ > This mostly looks good to me. > > One observation is that is the return from loadConfig isn't clear. > What would you think about adding STS_ERROR (-1) so that it's clear > from loadConfig and the caller that this is the error case. In the > original code there ere several status values and the IS_XXX macros > were used to check them. > > -Alan. From mark.sheppard at oracle.com Thu Mar 13 18:51:52 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Thu, 13 Mar 2014 18:51:52 +0000 Subject: RFR: JDK-8036600 - JNI exception pending in src/jdk/src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c Message-ID: <5321FE48.2090901@oracle.com> Hi Please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8036600/webrev/ which address the issues raised in https://bugs.openjdk.java.net/browse/JDK-8036600 summary: main changes are to check JNI return values, malloc returns and raise JNU_ThrowOutOfMemoryError as needed regards Mark From mark.sheppard at oracle.com Thu Mar 13 20:00:30 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Thu, 13 Mar 2014 20:00:30 +0000 Subject: RFR: JDK-8035571 - Check jdk/src/windows/native/java/net/TwoStacksPlain* for JNI pending exceptions Message-ID: <53220E5E.4080004@oracle.com> Hi Please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8035571/webrev/ which address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8035571 summary: JNI return value and pending exception checks added From Alan.Bateman at oracle.com Thu Mar 13 21:35:43 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 13 Mar 2014 21:35:43 +0000 Subject: RFR: JDK-8036600 - JNI exception pending in src/jdk/src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c In-Reply-To: <5321FE48.2090901@oracle.com> References: <5321FE48.2090901@oracle.com> Message-ID: <532224AF.50208@oracle.com> On 13/03/2014 18:51, Mark Sheppard wrote: > Hi > Please oblige and review the following changes > http://cr.openjdk.java.net/~msheppar/8036600/webrev/ > > which address the issues raised in > https://bugs.openjdk.java.net/browse/JDK-8036600 > > summary: > main changes are to check JNI return values, malloc returns and raise > JNU_ThrowOutOfMemoryError > as needed This looks okay to me. -Alan From mark.sheppard at oracle.com Fri Mar 14 19:04:43 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Fri, 14 Mar 2014 19:04:43 +0000 Subject: RFR: JDK-8035631 - JNI exception pending in jdk/src/windows/native/java/net/NetworkInterface_winXP.c Message-ID: <532352CB.5000609@oracle.com> Hi Please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8035631/webrev/ which address the issues raised in https://bugs.openjdk.java.net/browse/JDK-8035631 Summary: added CHECK_NULL_RETURN after JNI calls regards Mark From pavel.rappo at oracle.com Wed Mar 19 18:03:41 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 19 Mar 2014 18:03:41 +0000 Subject: RFR JDK-8035158: Remove dependency on sun.misc.RegexpPool and friends Message-ID: <5329DBFD.7080504@oracle.com> Hi everyone, could you please review my change for JDK-8035158? DefaultProxySelector uses sun.misc.RegexpPool to parse properties that configure the proxy settings. This code should be changed to use java.util.regex public API so that the classes in sun.misc.Regex* can be removed. http://cr.openjdk.java.net/~chegar/8035158/webrev.00/ The main idea was to get rid of dependency on private regex engine and to use public API which is available since jdk4 -- java.util.regex.Pattern. Thanks Pavel P.S. During this refactoring I may have found an erroneous behavior. In the current implementation when a duplicate disjunct is added into http.nonProxyHosts (as well as into ftp.nonProxyHosts) property, sun.misc.RegexpPool throws an exception: throw new java.misc.REException(re + " is a duplicate"); Later while slicing pattern into a sequence of disjuncts sun.net.spi.DefaultProxySelector silently swallows this exception: StringTokenizer st = new StringTokenizer(nphosts, "|", false); try { while (st.hasMoreTokens()) { pool.add(st.nextToken().toLowerCase(), Boolean.TRUE); } } catch (sun.misc.REException ex) {} // *** That leads to a situation where resulting pattern is broken. Moreover the final result depends on a position of the duplicate in the property -- as the while loop abrupted as a whole, not just a single iteration. In my case I was testing with http.nonProxyHosts=localhost when noticed this issue. In the list of default loopback aliases localhost happens to sit first: String defStringVal = "localhost|127.*|[::1]|0.0.0.0|[::0]; So when you set a value of http.nonProxyHosts to a "localhost", the only host you'll be able to go directly to will be that localhost. Because nothing else will have chance to be added into the pool after the exception is thrown. That's the only behavior I've modified by now. From anton.litvinov at oracle.com Thu Mar 20 14:08:35 2014 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Thu, 20 Mar 2014 18:08:35 +0400 Subject: [9] Review request for 8032832: Applet/browser deadlocks, when IIS integrated authentication is used Message-ID: <532AF663.1010200@oracle.com> Hello, Could you please review the following fix for the bug, which consists in a deadlock between 2 threads sharing the same instance of "java.net.URLClassLoader" as the context class loader, calling "sun.net.www.protocol.http.NegotiateAuthentication.isSupported" method and loading a class file from the web server with the enabled "Negotiate" authentication. Bug: https://bugs.openjdk.java.net/browse/JDK-8032832 Webrev: http://cr.openjdk.java.net/~alitvinov/8032832/jdk9/webrev.00 The fix is based on supplementing the method "sun.net.www.protocol.http.NegotiateAuthentication.isSupported" with the code locking on the instance of the class loader before existing locking on the class "sun.net.www.protocol.http.NegotiateAuthentication". Thank you, Anton From chris.hegarty at oracle.com Fri Mar 21 09:58:11 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 21 Mar 2014 09:58:11 +0000 Subject: RFR JDK-8035158: Remove dependency on sun.misc.RegexpPool and friends In-Reply-To: <5329DBFD.7080504@oracle.com> References: <5329DBFD.7080504@oracle.com> Message-ID: <532C0D33.3050106@oracle.com> Thanks for doing this Pavel. The changes, and test, look good to me. I can sponsor this for you. -Chris. On 19/03/14 18:03, Pavel Rappo wrote: > Hi everyone, > > could you please review my change for JDK-8035158? > > DefaultProxySelector uses sun.misc.RegexpPool to parse properties that > configure the proxy settings. This code should be changed to use > java.util.regex public API so that the classes in sun.misc.Regex* can be > removed. > > http://cr.openjdk.java.net/~chegar/8035158/webrev.00/ > > The main idea was to get rid of dependency on private regex engine and > to use public API which is available since jdk4 -- java.util.regex.Pattern. > > Thanks > Pavel > > P.S. During this refactoring I may have found an erroneous behavior. In > the current implementation when a duplicate disjunct is added into > http.nonProxyHosts (as well as into ftp.nonProxyHosts) property, > sun.misc.RegexpPool throws an exception: > > throw new java.misc.REException(re + " is a duplicate"); > > Later while slicing pattern into a sequence of disjuncts > sun.net.spi.DefaultProxySelector silently swallows this exception: > > StringTokenizer st = new StringTokenizer(nphosts, "|", false); > try { > while (st.hasMoreTokens()) { > pool.add(st.nextToken().toLowerCase(), Boolean.TRUE); > } > } catch (sun.misc.REException ex) {} // *** > > That leads to a situation where resulting pattern is broken. Moreover > the final result depends on a position of the duplicate in the property > -- as the while loop abrupted as a whole, not just a single iteration. > > In my case I was testing with http.nonProxyHosts=localhost when noticed > this issue. In the list of default loopback aliases localhost happens to > sit first: > > String defStringVal = "localhost|127.*|[::1]|0.0.0.0|[::0]; > > So when you set a value of http.nonProxyHosts to a "localhost", the only > host you'll be able to go directly to will be that localhost. Because > nothing else will have chance to be added into the pool after the > exception is thrown. > > That's the only behavior I've modified by now. From chris.hegarty at oracle.com Fri Mar 21 09:59:31 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 21 Mar 2014 09:59:31 +0000 Subject: RFR JDK-8035158: Remove dependency on sun.misc.RegexpPool and friends In-Reply-To: <5329DBFD.7080504@oracle.com> References: <5329DBFD.7080504@oracle.com> Message-ID: <532C0D83.6080700@oracle.com> Thanks for doing this Pavel. The changes, and test, look good to me. I can sponsor this for you. I assume that once this changes is pushed, JDK-8037781: "Remove sun.misc.Regexp* classes", can proceed. -Chris. On 19/03/14 18:03, Pavel Rappo wrote: > Hi everyone, > > could you please review my change for JDK-8035158? > > DefaultProxySelector uses sun.misc.RegexpPool to parse properties that > configure the proxy settings. This code should be changed to use > java.util.regex public API so that the classes in sun.misc.Regex* can be > removed. > > http://cr.openjdk.java.net/~chegar/8035158/webrev.00/ > > The main idea was to get rid of dependency on private regex engine and > to use public API which is available since jdk4 -- java.util.regex.Pattern. > > Thanks > Pavel > > P.S. During this refactoring I may have found an erroneous behavior. In > the current implementation when a duplicate disjunct is added into > http.nonProxyHosts (as well as into ftp.nonProxyHosts) property, > sun.misc.RegexpPool throws an exception: > > throw new java.misc.REException(re + " is a duplicate"); > > Later while slicing pattern into a sequence of disjuncts > sun.net.spi.DefaultProxySelector silently swallows this exception: > > StringTokenizer st = new StringTokenizer(nphosts, "|", false); > try { > while (st.hasMoreTokens()) { > pool.add(st.nextToken().toLowerCase(), Boolean.TRUE); > } > } catch (sun.misc.REException ex) {} // *** > > That leads to a situation where resulting pattern is broken. Moreover > the final result depends on a position of the duplicate in the property > -- as the while loop abrupted as a whole, not just a single iteration. > > In my case I was testing with http.nonProxyHosts=localhost when noticed > this issue. In the list of default loopback aliases localhost happens to > sit first: > > String defStringVal = "localhost|127.*|[::1]|0.0.0.0|[::0]; > > So when you set a value of http.nonProxyHosts to a "localhost", the only > host you'll be able to go directly to will be that localhost. Because > nothing else will have chance to be added into the pool after the > exception is thrown. > > That's the only behavior I've modified by now. From michael.x.mcmahon at oracle.com Fri Mar 21 10:43:56 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 21 Mar 2014 10:43:56 +0000 Subject: RFR JDK-8035158: Remove dependency on sun.misc.RegexpPool and friends In-Reply-To: <532C0D33.3050106@oracle.com> References: <5329DBFD.7080504@oracle.com> <532C0D33.3050106@oracle.com> Message-ID: <532C17EC.4050802@oracle.com> On 21/03/14 09:58, Chris Hegarty wrote: > Thanks for doing this Pavel. The changes, and test, look good to me. I > can sponsor this for you. > > -Chris. > +1. Looks good here too. Michael > On 19/03/14 18:03, Pavel Rappo wrote: >> Hi everyone, >> >> could you please review my change for JDK-8035158? >> >> DefaultProxySelector uses sun.misc.RegexpPool to parse properties that >> configure the proxy settings. This code should be changed to use >> java.util.regex public API so that the classes in sun.misc.Regex* can be >> removed. >> >> http://cr.openjdk.java.net/~chegar/8035158/webrev.00/ >> >> The main idea was to get rid of dependency on private regex engine and >> to use public API which is available since jdk4 -- >> java.util.regex.Pattern. >> >> Thanks >> Pavel >> >> P.S. During this refactoring I may have found an erroneous behavior. In >> the current implementation when a duplicate disjunct is added into >> http.nonProxyHosts (as well as into ftp.nonProxyHosts) property, >> sun.misc.RegexpPool throws an exception: >> >> throw new java.misc.REException(re + " is a duplicate"); >> >> Later while slicing pattern into a sequence of disjuncts >> sun.net.spi.DefaultProxySelector silently swallows this exception: >> >> StringTokenizer st = new StringTokenizer(nphosts, "|", false); >> try { >> while (st.hasMoreTokens()) { >> pool.add(st.nextToken().toLowerCase(), Boolean.TRUE); >> } >> } catch (sun.misc.REException ex) {} // *** >> >> That leads to a situation where resulting pattern is broken. Moreover >> the final result depends on a position of the duplicate in the property >> -- as the while loop abrupted as a whole, not just a single iteration. >> >> In my case I was testing with http.nonProxyHosts=localhost when noticed >> this issue. In the list of default loopback aliases localhost happens to >> sit first: >> >> String defStringVal = "localhost|127.*|[::1]|0.0.0.0|[::0]; >> >> So when you set a value of http.nonProxyHosts to a "localhost", the only >> host you'll be able to go directly to will be that localhost. Because >> nothing else will have chance to be added into the pool after the >> exception is thrown. >> >> That's the only behavior I've modified by now. From chris.hegarty at oracle.com Fri Mar 21 13:43:47 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 21 Mar 2014 13:43:47 +0000 Subject: RFR: JDK-8035631 - JNI exception pending in jdk/src/windows/native/java/net/NetworkInterface_winXP.c In-Reply-To: <532352CB.5000609@oracle.com> References: <532352CB.5000609@oracle.com> Message-ID: <532C4213.8000108@oracle.com> This looks ok to me Mark. You have added a question/comment on L514. Is this intentional? L555. Not directly related to your changes, but should netaddrP be freed there before returning NULL? -Chris. On 14/03/14 19:04, Mark Sheppard wrote: > Hi > > Please oblige and review the following changes > http://cr.openjdk.java.net/~msheppar/8035631/webrev/ > > which address the issues raised in > https://bugs.openjdk.java.net/browse/JDK-8035631 > > Summary: > added CHECK_NULL_RETURN after JNI calls > > regards > Mark > From mark.sheppard at oracle.com Fri Mar 21 14:04:35 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Fri, 21 Mar 2014 14:04:35 +0000 Subject: RFR: JDK-8035631 - JNI exception pending in jdk/src/windows/native/java/net/NetworkInterface_winXP.c In-Reply-To: <532C4213.8000108@oracle.com> References: <532352CB.5000609@oracle.com> <532C4213.8000108@oracle.com> Message-ID: <532C46F3.7020801@oracle.com> Hi Chris, thanks for the review ... yes, the question is intentional. the freeing of netaddrP is inconsistent on the NULL returns, so I just flagged it to solicit opinion from those more familiar with this code, to see if netaddrP should be freed prior to return ... L555 is another case as you have pointed out. netaddrP is obtained from the ifs in parameter. Interestingly, a "normal" return doesn't seem to free netaddrP. so its a minor conundrum regards Mark On 21/03/2014 13:43, Chris Hegarty wrote: > This looks ok to me Mark. > > You have added a question/comment on L514. Is this intentional? > > L555. Not directly related to your changes, but should netaddrP be > freed there before returning NULL? > > -Chris. > > On 14/03/14 19:04, Mark Sheppard wrote: >> Hi >> >> Please oblige and review the following changes >> http://cr.openjdk.java.net/~msheppar/8035631/webrev/ >> >> which address the issues raised in >> https://bugs.openjdk.java.net/browse/JDK-8035631 >> >> Summary: >> added CHECK_NULL_RETURN after JNI calls >> >> regards >> Mark >> From pavel.rappo at oracle.com Fri Mar 21 15:03:11 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 21 Mar 2014 15:03:11 +0000 Subject: RFR JDK-8035158: Remove dependency on sun.misc.RegexpPool and friends In-Reply-To: <532C0D83.6080700@oracle.com> References: <5329DBFD.7080504@oracle.com> <532C0D83.6080700@oracle.com> Message-ID: Hi Chris, JDK-8037781 will be sent to code review as soon as JDK-8035158 (this) is closed. Thanks. Pavel On 21 Mar 2014, at 09:59, Chris Hegarty wrote: > Thanks for doing this Pavel. The changes, and test, look good to me. I can sponsor this for you. > > I assume that once this changes is pushed, JDK-8037781: "Remove sun.misc.Regexp* classes", can proceed. > > -Chris. > > On 19/03/14 18:03, Pavel Rappo wrote: >> Hi everyone, >> >> could you please review my change for JDK-8035158? >> >> DefaultProxySelector uses sun.misc.RegexpPool to parse properties that >> configure the proxy settings. This code should be changed to use >> java.util.regex public API so that the classes in sun.misc.Regex* can be >> removed. >> >> http://cr.openjdk.java.net/~chegar/8035158/webrev.00/ >> >> The main idea was to get rid of dependency on private regex engine and >> to use public API which is available since jdk4 -- java.util.regex.Pattern. >> >> Thanks >> Pavel >> >> P.S. During this refactoring I may have found an erroneous behavior. In >> the current implementation when a duplicate disjunct is added into >> http.nonProxyHosts (as well as into ftp.nonProxyHosts) property, >> sun.misc.RegexpPool throws an exception: >> >> throw new java.misc.REException(re + " is a duplicate"); >> >> Later while slicing pattern into a sequence of disjuncts >> sun.net.spi.DefaultProxySelector silently swallows this exception: >> >> StringTokenizer st = new StringTokenizer(nphosts, "|", false); >> try { >> while (st.hasMoreTokens()) { >> pool.add(st.nextToken().toLowerCase(), Boolean.TRUE); >> } >> } catch (sun.misc.REException ex) {} // *** >> >> That leads to a situation where resulting pattern is broken. Moreover >> the final result depends on a position of the duplicate in the property >> -- as the while loop abrupted as a whole, not just a single iteration. >> >> In my case I was testing with http.nonProxyHosts=localhost when noticed >> this issue. In the list of default loopback aliases localhost happens to >> sit first: >> >> String defStringVal = "localhost|127.*|[::1]|0.0.0.0|[::0]; >> >> So when you set a value of http.nonProxyHosts to a "localhost", the only >> host you'll be able to go directly to will be that localhost. Because >> nothing else will have chance to be added into the pool after the >> exception is thrown. >> >> That's the only behavior I've modified by now. From michael.x.mcmahon at oracle.com Fri Mar 21 16:45:44 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 21 Mar 2014 16:45:44 +0000 Subject: RFR: JDK-8035631 - JNI exception pending in jdk/src/windows/native/java/net/NetworkInterface_winXP.c In-Reply-To: <532C46F3.7020801@oracle.com> References: <532352CB.5000609@oracle.com> <532C4213.8000108@oracle.com> <532C46F3.7020801@oracle.com> Message-ID: <532C6CB8.3060202@oracle.com> Hi Mark, I think in the normal case, the memory is freed by the calling function. It looks like the other cases aren't consistent though. Michael On 21/03/14 14:04, Mark Sheppard wrote: > Hi Chris, > thanks for the review ... yes, the question is intentional. > the freeing of netaddrP is inconsistent on the NULL returns, so I just > flagged it to > solicit opinion from those more familiar with this code, to > see if netaddrP should be freed prior to return ... L555 is another > case as you have pointed out. > netaddrP is obtained from the ifs in parameter. > Interestingly, a "normal" return doesn't seem to free netaddrP. > so its a minor conundrum > > regards > Mark > > > On 21/03/2014 13:43, Chris Hegarty wrote: >> This looks ok to me Mark. >> >> You have added a question/comment on L514. Is this intentional? >> >> L555. Not directly related to your changes, but should netaddrP be >> freed there before returning NULL? >> >> -Chris. >> >> On 14/03/14 19:04, Mark Sheppard wrote: >>> Hi >>> >>> Please oblige and review the following changes >>> http://cr.openjdk.java.net/~msheppar/8035631/webrev/ >>> >>> which address the issues raised in >>> https://bugs.openjdk.java.net/browse/JDK-8035631 >>> >>> Summary: >>> added CHECK_NULL_RETURN after JNI calls >>> >>> regards >>> Mark >>> > From xuelei.fan at oracle.com Fri Mar 21 23:38:44 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 22 Mar 2014 07:38:44 +0800 Subject: Review Request of JDK Enhancement Proposal: DTLS In-Reply-To: <20140321002829.GB9508@mhcomputing.net> References: <532A25EA.7040802@oracle.com> <20140320003158.GA5754@mhcomputing.net> <532A3B53.6000407@oracle.com> <532B3406.1030607@oracle.com> <532B72AA.7080102@oracle.com> <20140321002829.GB9508@mhcomputing.net> Message-ID: <532CCD84.1030400@oracle.com> Networking experts, any suggestion? Xuelei On 3/21/2014 8:28 AM, Matthew Hall wrote: > On Fri, Mar 21, 2014 at 06:58:50AM +0800, Xuelei Fan wrote: >> here. Although MTU is not PMTU, but it is normally "correct". > > I would state, not "normally correct", but "frequently correct". > > In case of IPSEC, SSL VPN, IPv6, GRE, etc. this will not be true. Many of > these are used for Site-to-Site VPN, which will appear often in the context of > RTP packets and SRTP packets, which happen to travel over VPNs. > >> It would be great if there is PMTU discovery API in Java, which can >> simplify the implementation of DTLS. > > Without it, I think there will be a lot of odd bugs occurring. > > Matthew. > -------------- next part -------------- An embedded message was scrubbed... From: Xuelei Fan Subject: Re: Review Request of JDK Enhancement Proposal: DTLS Date: Thu, 20 Mar 2014 08:50:27 +0800 Size: 1965 URL: From christos at zoulas.com Fri Mar 21 23:46:22 2014 From: christos at zoulas.com (Christos Zoulas) Date: Fri, 21 Mar 2014 19:46:22 -0400 Subject: Review Request of JDK Enhancement Proposal: DTLS In-Reply-To: <532CCD84.1030400@oracle.com> from Xuelei Fan (Mar 22, 7:38am) Message-ID: <20140321234622.73BAA17FDA1@rebar.astron.com> On Mar 22, 7:38am, xuelei.fan at oracle.com (Xuelei Fan) wrote: -- Subject: Re: Review Request of JDK Enhancement Proposal: DTLS | Networking experts, any suggestion? I have not seen pmtu exposed at the application layer before. Has anyone else? christos | | Xuelei | | On 3/21/2014 8:28 AM, Matthew Hall wrote: | > On Fri, Mar 21, 2014 at 06:58:50AM +0800, Xuelei Fan wrote: | >> here. Although MTU is not PMTU, but it is normally "correct". | > | > I would state, not "normally correct", but "frequently correct". | > | > In case of IPSEC, SSL VPN, IPv6, GRE, etc. this will not be true. Many of | > these are used for Site-to-Site VPN, which will appear often in the context of | > RTP packets and SRTP packets, which happen to travel over VPNs. | > | >> It would be great if there is PMTU discovery API in Java, which can | >> simplify the implementation of DTLS. | > | > Without it, I think there will be a lot of odd bugs occurring. | > | > Matthew. | > | | | --------------090406030702020009070402 | Content-Type: message/rfc822; | name="Attached Message" | Content-Transfer-Encoding: 7bit | Content-Disposition: attachment; | filename="Attached Message" | | Message-ID: <532A3B53.6000407 at oracle.com> | Date: Thu, 20 Mar 2014 08:50:27 +0800 | From: Xuelei Fan | User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 | MIME-Version: 1.0 | To: Matthew Hall | CC: OpenJDK | Subject: Re: Review Request of JDK Enhancement Proposal: DTLS | References: <532A25EA.7040802 at oracle.com> <20140320003158.GA5754 at mhcomputing.net> | In-Reply-To: <20140320003158.GA5754 at mhcomputing.net> | Content-Type: text/plain; charset=ISO-8859-1 | Content-Transfer-Encoding: 7bit | | PMTU is a key point of the design. I was wondering to expose this | application layer as a configurable parameter. If it is too big (or not | configured), DTLSEngine(let call it temporarily) will downgrade the size | automatically, just as the previous messages get lost. | | It's good point that need a separate spec to determine the PMTU. I will | see what we can do here. | | Thanks, | Xuelei | | On 3/20/2014 8:31 AM, Matthew Hall wrote: | > Xuelei, | > | > Is there an existing method for determining valid PMTU from inside of Java? If | > not then supplying correct segment size to whatever DTLSEngine (or however | > it's named) class would be non-trivial and could require native code. | > | > If there is not such support, then a separate spec would be needed to add that | > support, before it would be possible to get the new DTLS support to work very | > reliably. | > | > Matthew. | > | > On Thu, Mar 20, 2014 at 07:19:06AM +0800, Xuelei Fan wrote: | >> Hi, | >> | >> Please review the JDK Enhancement Proposal, Support Datagram Transport | >> Layer Security (DTLS) version 1.0 (RFC 4347) and 1.2 (RFC 6347) in the | >> JSSE API and the SunJSSE security provider. Detailed, please refer to | >> the draft JEP: | >> | >> http://cr.openjdk.java.net/~xuelei/7093601/jep-dtls-v00.txt | >> | >> Feel free to make comment and send your feedback to the alias. | >> | >> Thanks, | >> Xuelei | | | --------------090406030702020009070402-- -- End of excerpt from Xuelei Fan From mhall at mhcomputing.net Sat Mar 22 06:48:46 2014 From: mhall at mhcomputing.net (Matthew Hall) Date: Fri, 21 Mar 2014 23:48:46 -0700 Subject: Review Request of JDK Enhancement Proposal: DTLS In-Reply-To: <20140321234622.73BAA17FDA1@rebar.astron.com> References: <532CCD84.1030400@oracle.com> <20140321234622.73BAA17FDA1@rebar.astron.com> Message-ID: <20140322064846.GA14432@mhcomputing.net> The following bug and source code [1] are present in OpenSSL: http://rt.openssl.org/Ticket/Display.html?id=1929 I think something similar could be done in the JDK, by making some tweaks to the SocketOptions classes to expose some more options. I'm pretty sure something relating to this will work in POSIX JDK for Linux, Solaris, OS X, but not sure what different magic would be needed for Windows. Then there could be some kind of way to generate the right discovery datagrams, figure out the result, and feed it to the DTLSEngine for packetization purposes. Also, there is some DTLS capability in Bouncy Castle, we could see what they allow in terms of packetization as well, though I doubt they'll have what OpenSSL has, since IP_MTU_DISCOVER is probably not available to them either. I am glad you guys are working on this... I already have some use cases in mind for it! :-D Matthew. Reference [1]: case BIO_CTRL_DGRAM_MTU_DISCOVER: #if defined(OPENSSL_SYS_LINUX) && defined(IP_MTU_DISCOVER) && defined(IP_PMTUDISC_DO) addr_len = (socklen_t)sizeof(addr); memset((void *)&addr, 0, sizeof(addr)); if (getsockname(b->num, &addr.sa, &addr_len) < 0) { ret = 0; break; } switch (addr.sa.sa_family) { case AF_INET: sockopt_val = IP_PMTUDISC_DO; if ((ret = setsockopt(b->num, IPPROTO_IP, IP_MTU_DISCOVER, &sockopt_val, sizeof(sockopt_val))) < 0) perror("setsockopt"); break; #if OPENSSL_USE_IPV6 && defined(IPV6_MTU_DISCOVER) && defined(IPV6_PMTUDISC_DO) case AF_INET6: sockopt_val = IPV6_PMTUDISC_DO; if ((ret = setsockopt(b->num, IPPROTO_IPV6, IPV6_MTU_DISCOVER, &sockopt_val, sizeof(sockopt_val))) < 0) perror("setsockopt"); break; #endif On Fri, Mar 21, 2014 at 07:46:22PM -0400, Christos Zoulas wrote: > On Mar 22, 7:38am, xuelei.fan at oracle.com (Xuelei Fan) wrote: > -- Subject: Re: Review Request of JDK Enhancement Proposal: DTLS > > | Networking experts, any suggestion? > > I have not seen pmtu exposed at the application layer before. Has anyone > else? > > christos > > | > | Xuelei > | > | On 3/21/2014 8:28 AM, Matthew Hall wrote: > | > On Fri, Mar 21, 2014 at 06:58:50AM +0800, Xuelei Fan wrote: > | >> here. Although MTU is not PMTU, but it is normally "correct". > | > > | > I would state, not "normally correct", but "frequently correct". > | > > | > In case of IPSEC, SSL VPN, IPv6, GRE, etc. this will not be true. Many of > | > these are used for Site-to-Site VPN, which will appear often in the context of > | > RTP packets and SRTP packets, which happen to travel over VPNs. > | > > | >> It would be great if there is PMTU discovery API in Java, which can > | >> simplify the implementation of DTLS. > | > > | > Without it, I think there will be a lot of odd bugs occurring. > | > > | > Matthew. > | > > | > | > | --------------090406030702020009070402 > | Content-Type: message/rfc822; > | name="Attached Message" > | Content-Transfer-Encoding: 7bit > | Content-Disposition: attachment; > | filename="Attached Message" > | > | Message-ID: <532A3B53.6000407 at oracle.com> > | Date: Thu, 20 Mar 2014 08:50:27 +0800 > | From: Xuelei Fan > | User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 > | MIME-Version: 1.0 > | To: Matthew Hall > | CC: OpenJDK > | Subject: Re: Review Request of JDK Enhancement Proposal: DTLS > | References: <532A25EA.7040802 at oracle.com> <20140320003158.GA5754 at mhcomputing.net> > | In-Reply-To: <20140320003158.GA5754 at mhcomputing.net> > | Content-Type: text/plain; charset=ISO-8859-1 > | Content-Transfer-Encoding: 7bit > | > | PMTU is a key point of the design. I was wondering to expose this > | application layer as a configurable parameter. If it is too big (or not > | configured), DTLSEngine(let call it temporarily) will downgrade the size > | automatically, just as the previous messages get lost. > | > | It's good point that need a separate spec to determine the PMTU. I will > | see what we can do here. > | > | Thanks, > | Xuelei > | > | On 3/20/2014 8:31 AM, Matthew Hall wrote: > | > Xuelei, > | > > | > Is there an existing method for determining valid PMTU from inside of Java? If > | > not then supplying correct segment size to whatever DTLSEngine (or however > | > it's named) class would be non-trivial and could require native code. > | > > | > If there is not such support, then a separate spec would be needed to add that > | > support, before it would be possible to get the new DTLS support to work very > | > reliably. > | > > | > Matthew. > | > > | > On Thu, Mar 20, 2014 at 07:19:06AM +0800, Xuelei Fan wrote: > | >> Hi, > | >> > | >> Please review the JDK Enhancement Proposal, Support Datagram Transport > | >> Layer Security (DTLS) version 1.0 (RFC 4347) and 1.2 (RFC 6347) in the > | >> JSSE API and the SunJSSE security provider. Detailed, please refer to > | >> the draft JEP: > | >> > | >> http://cr.openjdk.java.net/~xuelei/7093601/jep-dtls-v00.txt > | >> > | >> Feel free to make comment and send your feedback to the alias. > | >> > | >> Thanks, > | >> Xuelei > | > | > | --------------090406030702020009070402-- > -- End of excerpt from Xuelei Fan > > From chris.hegarty at oracle.com Sat Mar 22 08:13:58 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 22 Mar 2014 08:13:58 +0000 Subject: RFR [9] 8034181: SIGBUS at Java_sun_nio_ch_SctpChannelImpl_receive0 Message-ID: <2115A3ED-B183-4D52-9E8A-2C5C7B438082@oracle.com> The native SCTP implementation assumes that the given byte buffer ( buffer address + position ) is memory aligned. It re-uses the buffer for handling notifications from the SCTP Stack ( as well as for reading data off the socket ). This can result in a SIBGUS on sparc(v9) if the address is not 4 byte aligned [1]. The trivial solution is to copy the SCTP notification into a stack allocated buffer, for handling, if the given address is not 4 byte aligned. http://cr.openjdk.java.net/~chegar/8034181/webev.00/webrev/ -Chris [1] https://bugs.openjdk.java.net/browse/JDK-8034181 From Alan.Bateman at oracle.com Sat Mar 22 08:19:14 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 22 Mar 2014 08:19:14 +0000 Subject: RFR [9] 8034181: SIGBUS at Java_sun_nio_ch_SctpChannelImpl_receive0 In-Reply-To: <2115A3ED-B183-4D52-9E8A-2C5C7B438082@oracle.com> References: <2115A3ED-B183-4D52-9E8A-2C5C7B438082@oracle.com> Message-ID: <532D4782.2010404@oracle.com> On 22/03/2014 08:13, Chris Hegarty wrote: > The native SCTP implementation assumes that the given byte buffer ( buffer address + position ) is memory aligned. It re-uses the buffer for handling notifications from the SCTP Stack ( as well as for reading data off the socket ). This can result in a SIBGUS on sparc(v9) if the address is not 4 byte aligned [1]. > > The trivial solution is to copy the SCTP notification into a stack allocated buffer, for handling, if the given address is not 4 byte aligned. > > http://cr.openjdk.java.net/~chegar/8034181/webev.00/webrev/ > It looks like the stack allocated buffer will be out of scope when you use it and I assume it would be safer to declare buf at L465 or so. -Alan. From chris.hegarty at oracle.com Sat Mar 22 08:24:38 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 22 Mar 2014 08:24:38 +0000 Subject: RFR [9] 8034181: SIGBUS at Java_sun_nio_ch_SctpChannelImpl_receive0 In-Reply-To: <532D4782.2010404@oracle.com> References: <2115A3ED-B183-4D52-9E8A-2C5C7B438082@oracle.com> <532D4782.2010404@oracle.com> Message-ID: On 22 Mar 2014, at 08:19, Alan Bateman wrote: > On 22/03/2014 08:13, Chris Hegarty wrote: >> The native SCTP implementation assumes that the given byte buffer ( buffer address + position ) is memory aligned. It re-uses the buffer for handling notifications from the SCTP Stack ( as well as for reading data off the socket ). This can result in a SIBGUS on sparc(v9) if the address is not 4 byte aligned [1]. >> >> The trivial solution is to copy the SCTP notification into a stack allocated buffer, for handling, if the given address is not 4 byte aligned. >> >> http://cr.openjdk.java.net/~chegar/8034181/webev.00/webrev/ >> > It looks like the stack allocated buffer will be out of scope when you use it and I assume it would be safer to declare buf at L465 or so. Good point. I did think about this, but wasn?t sure if it would cause problems. I?ll move it. -Chris. > > -Alan. From christos at zoulas.com Sat Mar 22 15:30:28 2014 From: christos at zoulas.com (Christos Zoulas) Date: Sat, 22 Mar 2014 11:30:28 -0400 Subject: Review Request of JDK Enhancement Proposal: DTLS In-Reply-To: <20140322064846.GA14432@mhcomputing.net> from Matthew Hall (Mar 21, 11:48pm) Message-ID: <20140322153028.72DB817FDA1@rebar.astron.com> On Mar 21, 11:48pm, mhall at mhcomputing.net (Matthew Hall) wrote: -- Subject: Re: Review Request of JDK Enhancement Proposal: DTLS | The following bug and source code [1] are present in OpenSSL: | | http://rt.openssl.org/Ticket/Display.html?id=1929 This link is not public. Can you post a summary? | I think something similar could be done in the JDK, by making some tweaks to | the SocketOptions classes to expose some more options. I'm pretty sure | something relating to this will work in POSIX JDK for Linux, Solaris, OS X, | but not sure what different magic would be needed for Windows. | | Then there could be some kind of way to generate the right discovery | datagrams, figure out the result, and feed it to the DTLSEngine for | packetization purposes. | | Also, there is some DTLS capability in Bouncy Castle, we could see what they | allow in terms of packetization as well, though I doubt they'll have what | OpenSSL has, since IP_MTU_DISCOVER is probably not available to them either. | | I am glad you guys are working on this... I already have some use cases in | mind for it! :-D So what happens on !linux? christos From mhall at mhcomputing.net Sat Mar 22 16:39:08 2014 From: mhall at mhcomputing.net (Matthew Hall) Date: Sat, 22 Mar 2014 09:39:08 -0700 Subject: Review Request of JDK Enhancement Proposal: DTLS In-Reply-To: <20140322153028.72DB817FDA1@rebar.astron.com> References: <20140322153028.72DB817FDA1@rebar.astron.com> Message-ID: Sorry about the hiccup. Supposedly the bug will work if you get in with user guest PW guest. As for non Windows, I don't know a lot of Windows programmers, only malware analysts. So we'd need to ask somebody in Sun's porting group I think. Or if somebody has a contact at Microsoft. Matthew. -- Sent from my mobile device. On March 22, 2014 8:30:28 AM PDT, christos at zoulas.com wrote: >On Mar 21, 11:48pm, mhall at mhcomputing.net (Matthew Hall) wrote: >-- Subject: Re: Review Request of JDK Enhancement Proposal: DTLS > >| The following bug and source code [1] are present in OpenSSL: >| >| http://rt.openssl.org/Ticket/Display.html?id=1929 > >This link is not public. Can you post a summary? > >| I think something similar could be done in the JDK, by making some >tweaks to >| the SocketOptions classes to expose some more options. I'm pretty >sure >| something relating to this will work in POSIX JDK for Linux, Solaris, >OS X, >| but not sure what different magic would be needed for Windows. >| >| Then there could be some kind of way to generate the right discovery >| datagrams, figure out the result, and feed it to the DTLSEngine for >| packetization purposes. >| >| Also, there is some DTLS capability in Bouncy Castle, we could see >what they >| allow in terms of packetization as well, though I doubt they'll have >what >| OpenSSL has, since IP_MTU_DISCOVER is probably not available to them >either. >| >| I am glad you guys are working on this... I already have some use >cases in >| mind for it! :-D > >So what happens on !linux? > >christos From christos at zoulas.com Sat Mar 22 17:14:28 2014 From: christos at zoulas.com (Christos Zoulas) Date: Sat, 22 Mar 2014 13:14:28 -0400 Subject: Review Request of JDK Enhancement Proposal: DTLS In-Reply-To: from Matthew Hall (Mar 22, 9:39am) Message-ID: <20140322171428.320E717FDA1@rebar.astron.com> On Mar 22, 9:39am, mhall at mhcomputing.net (Matthew Hall) wrote: -- Subject: Re: Review Request of JDK Enhancement Proposal: DTLS | Sorry about the hiccup. Supposedly the bug will work if you get in with user guest PW guest. Thanks. christos From dmitry.samersoff at oracle.com Sun Mar 23 09:37:06 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 23 Mar 2014 13:37:06 +0400 Subject: RFR [9] 8034181: SIGBUS at Java_sun_nio_ch_SctpChannelImpl_receive0 In-Reply-To: <2115A3ED-B183-4D52-9E8A-2C5C7B438082@oracle.com> References: <2115A3ED-B183-4D52-9E8A-2C5C7B438082@oracle.com> Message-ID: <532EAB42.5040607@oracle.com> Chris, It's better to check that rv is less than NOTIFICATION_BUFFER_SIZE. -Dmitry On 2014-03-22 12:13, Chris Hegarty wrote: > The native SCTP implementation assumes that the given byte buffer ( buffer address + position ) is memory aligned. It re-uses the buffer for handling notifications from the SCTP Stack ( as well as for reading data off the socket ). This can result in a SIBGUS on sparc(v9) if the address is not 4 byte aligned [1]. > > The trivial solution is to copy the SCTP notification into a stack allocated buffer, for handling, if the given address is not 4 byte aligned. > > http://cr.openjdk.java.net/~chegar/8034181/webev.00/webrev/ > > -Chris > > [1] https://bugs.openjdk.java.net/browse/JDK-8034181 > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From michael.x.mcmahon at oracle.com Mon Mar 24 11:52:09 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 24 Mar 2014 11:52:09 +0000 Subject: Review Request of JDK Enhancement Proposal: DTLS In-Reply-To: <20140322064846.GA14432@mhcomputing.net> References: <532CCD84.1030400@oracle.com> <20140321234622.73BAA17FDA1@rebar.astron.com> <20140322064846.GA14432@mhcomputing.net> Message-ID: <53301C69.2010808@oracle.com> My understanding is that the original PMTU discovery spec RFC 1191 is not very effective due to its reliance on ICMP messages that are often filtered out by routers. There was an update in RFC 4821 which removes the dependency on ICMP and that seems to be effective I'm just wondering then how DTLS expects it to be done? Michael. On 22/03/14 06:48, Matthew Hall wrote: > The following bug and source code [1] are present in OpenSSL: > > http://rt.openssl.org/Ticket/Display.html?id=1929 > > I think something similar could be done in the JDK, by making some tweaks to > the SocketOptions classes to expose some more options. I'm pretty sure > something relating to this will work in POSIX JDK for Linux, Solaris, OS X, > but not sure what different magic would be needed for Windows. > > Then there could be some kind of way to generate the right discovery > datagrams, figure out the result, and feed it to the DTLSEngine for > packetization purposes. > > Also, there is some DTLS capability in Bouncy Castle, we could see what they > allow in terms of packetization as well, though I doubt they'll have what > OpenSSL has, since IP_MTU_DISCOVER is probably not available to them either. > > I am glad you guys are working on this... I already have some use cases in > mind for it! :-D > > Matthew. > > Reference [1]: > > case BIO_CTRL_DGRAM_MTU_DISCOVER: > #if defined(OPENSSL_SYS_LINUX) && defined(IP_MTU_DISCOVER) && defined(IP_PMTUDISC_DO) > addr_len = (socklen_t)sizeof(addr); > memset((void *)&addr, 0, sizeof(addr)); > if (getsockname(b->num, &addr.sa, &addr_len) < 0) > { > ret = 0; > break; > } > switch (addr.sa.sa_family) > { > case AF_INET: > sockopt_val = IP_PMTUDISC_DO; > if ((ret = setsockopt(b->num, IPPROTO_IP, IP_MTU_DISCOVER, > &sockopt_val, sizeof(sockopt_val))) < 0) > perror("setsockopt"); > break; > #if OPENSSL_USE_IPV6 && defined(IPV6_MTU_DISCOVER) && defined(IPV6_PMTUDISC_DO) > case AF_INET6: > sockopt_val = IPV6_PMTUDISC_DO; > if ((ret = setsockopt(b->num, IPPROTO_IPV6, IPV6_MTU_DISCOVER, > &sockopt_val, sizeof(sockopt_val))) < 0) > perror("setsockopt"); > break; > #endif > > > On Fri, Mar 21, 2014 at 07:46:22PM -0400, Christos Zoulas wrote: >> On Mar 22, 7:38am, xuelei.fan at oracle.com (Xuelei Fan) wrote: >> -- Subject: Re: Review Request of JDK Enhancement Proposal: DTLS >> >> | Networking experts, any suggestion? >> >> I have not seen pmtu exposed at the application layer before. Has anyone >> else? >> >> christos >> >> | >> | Xuelei >> | >> | On 3/21/2014 8:28 AM, Matthew Hall wrote: >> | > On Fri, Mar 21, 2014 at 06:58:50AM +0800, Xuelei Fan wrote: >> | >> here. Although MTU is not PMTU, but it is normally "correct". >> | > >> | > I would state, not "normally correct", but "frequently correct". >> | > >> | > In case of IPSEC, SSL VPN, IPv6, GRE, etc. this will not be true. Many of >> | > these are used for Site-to-Site VPN, which will appear often in the context of >> | > RTP packets and SRTP packets, which happen to travel over VPNs. >> | > >> | >> It would be great if there is PMTU discovery API in Java, which can >> | >> simplify the implementation of DTLS. >> | > >> | > Without it, I think there will be a lot of odd bugs occurring. >> | > >> | > Matthew. >> | > >> | >> | >> | --------------090406030702020009070402 >> | Content-Type: message/rfc822; >> | name="Attached Message" >> | Content-Transfer-Encoding: 7bit >> | Content-Disposition: attachment; >> | filename="Attached Message" >> | >> | Message-ID: <532A3B53.6000407 at oracle.com> >> | Date: Thu, 20 Mar 2014 08:50:27 +0800 >> | From: Xuelei Fan >> | User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 >> | MIME-Version: 1.0 >> | To: Matthew Hall >> | CC: OpenJDK >> | Subject: Re: Review Request of JDK Enhancement Proposal: DTLS >> | References: <532A25EA.7040802 at oracle.com> <20140320003158.GA5754 at mhcomputing.net> >> | In-Reply-To: <20140320003158.GA5754 at mhcomputing.net> >> | Content-Type: text/plain; charset=ISO-8859-1 >> | Content-Transfer-Encoding: 7bit >> | >> | PMTU is a key point of the design. I was wondering to expose this >> | application layer as a configurable parameter. If it is too big (or not >> | configured), DTLSEngine(let call it temporarily) will downgrade the size >> | automatically, just as the previous messages get lost. >> | >> | It's good point that need a separate spec to determine the PMTU. I will >> | see what we can do here. >> | >> | Thanks, >> | Xuelei >> | >> | On 3/20/2014 8:31 AM, Matthew Hall wrote: >> | > Xuelei, >> | > >> | > Is there an existing method for determining valid PMTU from inside of Java? If >> | > not then supplying correct segment size to whatever DTLSEngine (or however >> | > it's named) class would be non-trivial and could require native code. >> | > >> | > If there is not such support, then a separate spec would be needed to add that >> | > support, before it would be possible to get the new DTLS support to work very >> | > reliably. >> | > >> | > Matthew. >> | > >> | > On Thu, Mar 20, 2014 at 07:19:06AM +0800, Xuelei Fan wrote: >> | >> Hi, >> | >> >> | >> Please review the JDK Enhancement Proposal, Support Datagram Transport >> | >> Layer Security (DTLS) version 1.0 (RFC 4347) and 1.2 (RFC 6347) in the >> | >> JSSE API and the SunJSSE security provider. Detailed, please refer to >> | >> the draft JEP: >> | >> >> | >> http://cr.openjdk.java.net/~xuelei/7093601/jep-dtls-v00.txt >> | >> >> | >> Feel free to make comment and send your feedback to the alias. >> | >> >> | >> Thanks, >> | >> Xuelei >> | >> | >> | --------------090406030702020009070402-- >> -- End of excerpt from Xuelei Fan >> >> From chris.hegarty at oracle.com Mon Mar 24 14:09:25 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 24 Mar 2014 14:09:25 +0000 Subject: RFR [9] 8034181: SIGBUS at Java_sun_nio_ch_SctpChannelImpl_receive0 In-Reply-To: <532D4782.2010404@oracle.com> References: <2115A3ED-B183-4D52-9E8A-2C5C7B438082@oracle.com> <532D4782.2010404@oracle.com> Message-ID: <53303C95.4080609@oracle.com> Alan, Dmitry, I updated the webrev. It now allocates memory dynamically, and asserts that the number of bytes read is less than the size of sctp_notification ( for notifications ). http://cr.openjdk.java.net/~chegar/8034181/webrev.01/webrev/ -Chris. On 22/03/14 08:19, Alan Bateman wrote: > On 22/03/2014 08:13, Chris Hegarty wrote: >> The native SCTP implementation assumes that the given byte buffer ( >> buffer address + position ) is memory aligned. It re-uses the buffer >> for handling notifications from the SCTP Stack ( as well as for >> reading data off the socket ). This can result in a SIBGUS on >> sparc(v9) if the address is not 4 byte aligned [1]. >> >> The trivial solution is to copy the SCTP notification into a stack >> allocated buffer, for handling, if the given address is not 4 byte >> aligned. >> >> http://cr.openjdk.java.net/~chegar/8034181/webev.00/webrev/ >> > It looks like the stack allocated buffer will be out of scope when you > use it and I assume it would be safer to declare buf at L465 or so. > > -Alan. From Alan.Bateman at oracle.com Mon Mar 24 16:17:43 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 24 Mar 2014 16:17:43 +0000 Subject: RFR [9] 8034181: SIGBUS at Java_sun_nio_ch_SctpChannelImpl_receive0 In-Reply-To: <53303C95.4080609@oracle.com> References: <2115A3ED-B183-4D52-9E8A-2C5C7B438082@oracle.com> <532D4782.2010404@oracle.com> <53303C95.4080609@oracle.com> Message-ID: <53305AA7.7080006@oracle.com> On 24/03/2014 14:09, Chris Hegarty wrote: > Alan, Dmitry, > > I updated the webrev. It now allocates memory dynamically, and asserts > that the number of bytes read is less than the size of > sctp_notification ( for notifications ). > > http://cr.openjdk.java.net/~chegar/8034181/webrev.01/webrev/ > > -Chris. This looks okay to me and I wouldn't expect the malloc'ed case to be common. One comment on the test is that "75" isn't obvious and might be useful as a constant at the top to explain that it's the total number of combinations. -Alan From chris.hegarty at oracle.com Mon Mar 24 16:25:27 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 24 Mar 2014 16:25:27 +0000 Subject: RFR [9] 8034181: SIGBUS at Java_sun_nio_ch_SctpChannelImpl_receive0 In-Reply-To: <53305AA7.7080006@oracle.com> References: <2115A3ED-B183-4D52-9E8A-2C5C7B438082@oracle.com> <532D4782.2010404@oracle.com> <53303C95.4080609@oracle.com> <53305AA7.7080006@oracle.com> Message-ID: <53305C77.3000006@oracle.com> On 24/03/14 16:17, Alan Bateman wrote: > On 24/03/2014 14:09, Chris Hegarty wrote: >> Alan, Dmitry, >> >> I updated the webrev. It now allocates memory dynamically, and asserts >> that the number of bytes read is less than the size of >> sctp_notification ( for notifications ). >> >> http://cr.openjdk.java.net/~chegar/8034181/webrev.01/webrev/ >> >> -Chris. > This looks okay to me and I wouldn't expect the malloc'ed case to be > common. > > One comment on the test is that "75" isn't obvious and might be useful > as a constant at the top to explain that it's the total number of > combinations. Thanks Alan. I'll do that before pushing. -Chris. > > -Alan From chris.hegarty at oracle.com Mon Mar 24 16:38:35 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 24 Mar 2014 16:38:35 +0000 Subject: [9] Review request for 8032832: Applet/browser deadlocks, when IIS integrated authentication is used In-Reply-To: <532AF663.1010200@oracle.com> References: <532AF663.1010200@oracle.com> Message-ID: <53305F8B.40102@oracle.com> Hi Anton, I don't have any objections to this, but Max is the original author of this code and may want to take a closer look. -Chris. On 20/03/14 14:08, Anton Litvinov wrote: > Hello, > > Could you please review the following fix for the bug, which consists in > a deadlock between 2 threads sharing the same instance of > "java.net.URLClassLoader" as the context class loader, calling > "sun.net.www.protocol.http.NegotiateAuthentication.isSupported" method > and loading a class file from the web server with the enabled > "Negotiate" authentication. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8032832 > Webrev: http://cr.openjdk.java.net/~alitvinov/8032832/jdk9/webrev.00 > > The fix is based on supplementing the method > "sun.net.www.protocol.http.NegotiateAuthentication.isSupported" with the > code locking on the instance of the class loader before existing locking > on the class "sun.net.www.protocol.http.NegotiateAuthentication". > > Thank you, > Anton From luchsh at linux.vnet.ibm.com Tue Mar 25 02:35:31 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Tue, 25 Mar 2014 10:35:31 +0800 Subject: Add IDN support to existing net APIs Message-ID: 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.mcmahon at 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.mcmahon at 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 "); >> >> >> 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 >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Mar 25 09:56:35 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 Mar 2014 09:56:35 +0000 Subject: Add IDN support to existing net APIs In-Reply-To: References: Message-ID: <533152D3.5010301@oracle.com> On 25/03/2014 02:35, Jonathan Lu wrote: > 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 Is the proposal only for a system property to configure (system-wide) the use of IDNs or are you also thinking about adding a new method to InetAddress to make it obvious when reading the code? -Alan. From anton.litvinov at oracle.com Tue Mar 25 10:48:49 2014 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Tue, 25 Mar 2014 14:48:49 +0400 Subject: [9] Review request for 8032832: Applet/browser deadlocks, when IIS integrated authentication is used In-Reply-To: <53305F8B.40102@oracle.com> References: <532AF663.1010200@oracle.com> <53305F8B.40102@oracle.com> Message-ID: <53315F11.3070607@oracle.com> Hello Chris, Thank you very much for review of this fix and for addressing the review request to the second possible reviewer. I am looking forward to receiving any response from Weijun Wang. Also I would like to inform you that jtreg regression tests specified below (both open and internal proprietary) were run on all 4 supported platforms: MS Windows, Linux, Solaris, OS X. The results of regression tests were almost identical on on all the platforms, however, no negative changes introduced by the fix were found. Executed regression tests: - "jdk/test/java/net" - "jdk/test/sun/net" Thank you, Anton On 3/24/2014 8:38 PM, Chris Hegarty wrote: > Hi Anton, > > I don't have any objections to this, but Max is the original author of > this code and may want to take a closer look. > > -Chris. > > On 20/03/14 14:08, Anton Litvinov wrote: >> Hello, >> >> Could you please review the following fix for the bug, which consists in >> a deadlock between 2 threads sharing the same instance of >> "java.net.URLClassLoader" as the context class loader, calling >> "sun.net.www.protocol.http.NegotiateAuthentication.isSupported" method >> and loading a class file from the web server with the enabled >> "Negotiate" authentication. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8032832 >> Webrev: http://cr.openjdk.java.net/~alitvinov/8032832/jdk9/webrev.00 >> >> The fix is based on supplementing the method >> "sun.net.www.protocol.http.NegotiateAuthentication.isSupported" with the >> code locking on the instance of the class loader before existing locking >> on the class "sun.net.www.protocol.http.NegotiateAuthentication". >> >> Thank you, >> Anton From weijun.wang at oracle.com Tue Mar 25 11:37:52 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 25 Mar 2014 19:37:52 +0800 Subject: [9] Review request for 8032832: Applet/browser deadlocks, when IIS integrated authentication is used In-Reply-To: <53315F11.3070607@oracle.com> References: <532AF663.1010200@oracle.com> <53305F8B.40102@oracle.com> <53315F11.3070607@oracle.com> Message-ID: <41652C12-74E8-49F5-B10E-646BFD3A455E@oracle.com> The fix looks fine. You might want to remove the cache-related words from the comment of the new isSupported method. --Max On Mar 25, 2014, at 18:48, Anton Litvinov wrote: > Hello Chris, > > Thank you very much for review of this fix and for addressing the review request to the second possible reviewer. I am looking forward to receiving any response from Weijun Wang. Also I would like to inform you that jtreg regression tests specified below (both open and internal proprietary) were run on all 4 supported platforms: MS Windows, Linux, Solaris, OS X. The results of regression tests were almost identical on on all the platforms, however, no negative changes introduced by the fix were found. > > Executed regression tests: > - "jdk/test/java/net" > - "jdk/test/sun/net" > > Thank you, > Anton > > On 3/24/2014 8:38 PM, Chris Hegarty wrote: >> Hi Anton, >> >> I don't have any objections to this, but Max is the original author of this code and may want to take a closer look. >> >> -Chris. >> >> On 20/03/14 14:08, Anton Litvinov wrote: >>> Hello, >>> >>> Could you please review the following fix for the bug, which consists in >>> a deadlock between 2 threads sharing the same instance of >>> "java.net.URLClassLoader" as the context class loader, calling >>> "sun.net.www.protocol.http.NegotiateAuthentication.isSupported" method >>> and loading a class file from the web server with the enabled >>> "Negotiate" authentication. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8032832 >>> Webrev: http://cr.openjdk.java.net/~alitvinov/8032832/jdk9/webrev.00 >>> >>> The fix is based on supplementing the method >>> "sun.net.www.protocol.http.NegotiateAuthentication.isSupported" with the >>> code locking on the instance of the class loader before existing locking >>> on the class "sun.net.www.protocol.http.NegotiateAuthentication". >>> >>> Thank you, >>> Anton > From anton.litvinov at oracle.com Tue Mar 25 12:27:27 2014 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Tue, 25 Mar 2014 16:27:27 +0400 Subject: [9] Review request for 8032832: Applet/browser deadlocks, when IIS integrated authentication is used In-Reply-To: <41652C12-74E8-49F5-B10E-646BFD3A455E@oracle.com> References: <532AF663.1010200@oracle.com> <53305F8B.40102@oracle.com> <53315F11.3070607@oracle.com> <41652C12-74E8-49F5-B10E-646BFD3A455E@oracle.com> Message-ID: <5331762F.1030200@oracle.com> Hello Max, Thank you for review and approval of the fix. The sentence containing cache-related words is removed from the comment of the new "isSupported" method. The edited version of the fix is following. Webrev: http://cr.openjdk.java.net/~alitvinov/8032832/jdk9/webrev.01 Thank you, Anton On 3/25/2014 3:37 PM, Wang Weijun wrote: > The fix looks fine. You might want to remove the cache-related words from the comment of the new isSupported method. > > --Max > > On Mar 25, 2014, at 18:48, Anton Litvinov wrote: > >> Hello Chris, >> >> Thank you very much for review of this fix and for addressing the review request to the second possible reviewer. I am looking forward to receiving any response from Weijun Wang. Also I would like to inform you that jtreg regression tests specified below (both open and internal proprietary) were run on all 4 supported platforms: MS Windows, Linux, Solaris, OS X. The results of regression tests were almost identical on on all the platforms, however, no negative changes introduced by the fix were found. >> >> Executed regression tests: >> - "jdk/test/java/net" >> - "jdk/test/sun/net" >> >> Thank you, >> Anton >> >> On 3/24/2014 8:38 PM, Chris Hegarty wrote: >>> Hi Anton, >>> >>> I don't have any objections to this, but Max is the original author of this code and may want to take a closer look. >>> >>> -Chris. >>> >>> On 20/03/14 14:08, Anton Litvinov wrote: >>>> Hello, >>>> >>>> Could you please review the following fix for the bug, which consists in >>>> a deadlock between 2 threads sharing the same instance of >>>> "java.net.URLClassLoader" as the context class loader, calling >>>> "sun.net.www.protocol.http.NegotiateAuthentication.isSupported" method >>>> and loading a class file from the web server with the enabled >>>> "Negotiate" authentication. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8032832 >>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8032832/jdk9/webrev.00 >>>> >>>> The fix is based on supplementing the method >>>> "sun.net.www.protocol.http.NegotiateAuthentication.isSupported" with the >>>> code locking on the instance of the class loader before existing locking >>>> on the class "sun.net.www.protocol.http.NegotiateAuthentication". >>>> >>>> Thank you, >>>> Anton From Alan.Bateman at oracle.com Wed Mar 26 08:43:04 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 26 Mar 2014 08:43:04 +0000 Subject: Add IDN support to existing net APIs In-Reply-To: References: <533152D3.5010301@oracle.com> Message-ID: <53329318.5090607@oracle.com> On 26/03/2014 02:58, Jonathan Lu wrote: > : > > Only for the system property to configure the use of IDNs and some > related code to do the checking and conversion, no plan to add new > methods to InetAddress. > Thanks, I'm just wondering whether it would make sense to add APIs. Michael - do you have any views on this? -Alan From michael.x.mcmahon at oracle.com Wed Mar 26 13:50:59 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 26 Mar 2014 13:50:59 +0000 Subject: Add IDN support to existing net APIs In-Reply-To: <53329318.5090607@oracle.com> References: <533152D3.5010301@oracle.com> <53329318.5090607@oracle.com> Message-ID: <5332DB43.7090904@oracle.com> On 26/03/14 08:43, Alan Bateman wrote: > On 26/03/2014 02:58, Jonathan Lu wrote: >> : >> >> Only for the system property to configure the use of IDNs and some >> related code to do the checking and conversion, no plan to add new >> methods to InetAddress. >> > Thanks, I'm just wondering whether it would make sense to add APIs. > Michael - do you have any views on this? > > -Alan I think perhaps a net property (as opposed to a system property) would be sufficient. An explicit API would probably need to be at a similar (global) scope. In other words, you would want all uses of Strings as hostnames to be converted to/from IDNs transparently and without needing additional API invocations. So, may be a property is just simpler. I assume the default initially would be for the property to be disabled by default? I know I raised the idea of filing a JEP for this, but maybe that's not necessary. If you are interested to do this work Jonathan, then I'd suggest maybe doing a survey first, to identify the relevant specifications (eg RFCs) that need to be complied with and then identify the places that we need to make changes (or a webrev of the changes if you like). And we could take it from there. Michael. From chris.hegarty at oracle.com Thu Mar 27 10:46:59 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 27 Mar 2014 10:46:59 +0000 Subject: RFR [9] 8038459: (sctp) Remove superflous classes on platforms without an implementation [macosx, aix] Message-ID: While hunting around the build recently, when working on another SCTP bug, I noticed a small issue where SCTP classes are being built on some platforms unnecessarily. Webrev: http://cr.openjdk.java.net/~chegar/8038459/webrev.00/webrev/ Mac OS X and AIX contain only stubs for the SCTP channels. There are platform specific versions of the stubs for these platforms, so the build currently filters out the three channel implementation classes, on these platforms. But, there are other implementation classes in src/solaris/classes/sun/nio/ch/sctp that are needed for Linux and Solaris. These classes should be filter out also, on platforms that do not require them ( Mac OS X and AIX ). Looking at rt. jar from a Mac JRE the superfluous classes can be seen: $ jar -tvf rt.jar | grep "sun/nio/ch/sctp" 2420 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/AssociationChange.class <<< NOT NEEDED 759 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/AssociationImpl.class <<< NOT NEEDED 2614 Thu Feb 27 23:47:04 GMT 2014 sun/nio/ch/sctp/MessageInfoImpl.class 2607 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/PeerAddrChange.class <<< NOT NEEDED 2793 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/ResultContainer.class <<< NOT NEEDED 2850 Thu Feb 27 23:47:10 GMT 2014 sun/nio/ch/sctp/SctpChannelImpl.class 2987 Thu Feb 27 23:47:10 GMT 2014 sun/nio/ch/sctp/SctpMultiChannelImpl.class 7712 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/SctpNet.class <<< NOT NEEDED 251 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/SctpNotification.class <<< NOT NEEDED 1935 Thu Feb 27 23:47:10 GMT 2014 sun/nio/ch/sctp/SctpServerChannelImpl.class 1379 Thu Feb 27 23:47:04 GMT 2014 sun/nio/ch/sctp/SctpStdSocketOption.class 1953 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/SendFailed.class <<< NOT NEEDED 1239 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/Shutdown.class <<< NOT NEEDED Note: SctpStdSocketOption.class and MessageInfoImpl.class are platform independent, and needed to support parts of the API that are not dependent on an actual socket implementation. -Chris. From amanda.jiang at oracle.com Fri Mar 28 05:07:50 2014 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Fri, 28 Mar 2014 00:07:50 -0500 Subject: RFR for JDK-8038276 java/net/NetworkInterface/Test.java fails on windows intermittently for Teredo Interface Message-ID: <533503A6.3090503@oracle.com> Hi All , Please check and review following changes: http://cr.openjdk.java.net/~ewang/amanda/JDK-8038276/webrev.00/ Description of issue: Root Cause: Test java/net/NetworkInterface/Test.java failed because virtual interface "Teredo Tunneling Pseudo-Interface" on windows returned random addresses, we should not test on that interface. Suggested Fixes: Remove windows&&Teredo Interfaces from test. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yiming.wang at oracle.com Fri Mar 28 05:54:31 2014 From: yiming.wang at oracle.com (Eric Wang) Date: Fri, 28 Mar 2014 13:54:31 +0800 Subject: RFR for bug JDK-8025209 Intermittent test failure: java/net/Socket/asyncClose/AsyncClose.java In-Reply-To: References: <5316F2FE.5040501@oracle.com> Message-ID: <53350E97.6050205@oracle.com> Hi Chris & All, Sorry that the fix spent a bit long time for internal review. Can you please review the fix below for bug JDK-8025209 . The fix is just to make the thread synchronization is more robust and made some cleanup. http://cr.openjdk.java.net/~ewang/JDK-8025209/webrev.00/ Thanks, Eric On 2014/3/5 18:01, Chris Hegarty wrote: > On 5 Mar 2014, at 09:48, Eric Wang wrote: > >> Hi everyone, >> >> Hi Everyone, >> >> I'm working on the test bug https://bugs.openjdk.java.net/browse/JDK-8025209, The test uses Thread.sleep to sync-up threads which is not a correct assumption. The fix is just to sync-up 2 threads using proper way. >> >> The webrev will be sent after internal review. Please let me know if you have any comment. > This test is part of the OpenJDK source. Please just post your webrev externally for review. > > Thanks, > -Chris. > >> Thanks, >> Eric >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Fri Mar 28 10:41:58 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 28 Mar 2014 10:41:58 +0000 Subject: RFR for bug JDK-8025209 Intermittent test failure: java/net/Socket/asyncClose/AsyncClose.java In-Reply-To: <53350E97.6050205@oracle.com> References: <5316F2FE.5040501@oracle.com> <53350E97.6050205@oracle.com> Message-ID: <533551F6.2050909@oracle.com> Hi Eric, I've taken a look at the webrev and I mainly agree with the changes/refactoring. On the issue of increasing the timeout to 20 secs; there is a clear race in this test, and your refactoring has reduced it as much as possible. Since the sleep will always occur, I would prefer to reduce it from 20 secs to 5 secs. That, in combination with your use of a latch, should be sufficient. Also, there is a variant of each test that runs with a 5,000 millisecond timeout. This timeout should be increased to 20,000 milliseconds. Otherwise, the blocking IO call may timeout rather than be interrupted ( which is what the test is testing for ). If you address the above issues, I will be happy to sponsor this change for you. -Chris. On 28/03/14 05:54, Eric Wang wrote: > Hi Chris & All, > > Sorry that the fix spent a bit long time for internal review. > Can you please review the fix below for bug JDK-8025209 > . The fix is just to > make the thread synchronization is more robust and made some cleanup. > http://cr.openjdk.java.net/~ewang/JDK-8025209/webrev.00/ > > Thanks, > Eric > On 2014/3/5 18:01, Chris Hegarty wrote: >> On 5 Mar 2014, at 09:48, Eric Wang wrote: >> >>> Hi everyone, >>> >>> Hi Everyone, >>> >>> I'm working on the test bughttps://bugs.openjdk.java.net/browse/JDK-8025209, The test uses Thread.sleep to sync-up threads which is not a correct assumption. The fix is just to sync-up 2 threads using proper way. >>> >>> The webrev will be sent after internal review. Please let me know if you have any comment. >> This test is part of the OpenJDK source. Please just post your webrev externally for review. >> >> Thanks, >> -Chris. >> >>> Thanks, >>> Eric >>> > From chris.hegarty at oracle.com Fri Mar 28 11:10:49 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 28 Mar 2014 11:10:49 +0000 Subject: RFR for JDK-8038276 java/net/NetworkInterface/Test.java fails on windows intermittently for Teredo Interface In-Reply-To: <533503A6.3090503@oracle.com> References: <533503A6.3090503@oracle.com> Message-ID: <533558B9.1080009@oracle.com> Looks ok to me Amanda. I can sponsor this change, if needed. -Chris. On 28/03/14 05:07, Amanda Jiang wrote: > Hi All , > > Please check and review following changes: > http://cr.openjdk.java.net/~ewang/amanda/JDK-8038276/webrev.00/ > > Description of issue: > Root Cause: > Test java/net/NetworkInterface/Test.java failed because virtual > interface "Teredo Tunneling Pseudo-Interface" on windows returned random > addresses, we should not test on that interface. > Suggested Fixes: > Remove windows&&Teredo Interfaces from test. From amanda.jiang at oracle.com Fri Mar 28 15:58:43 2014 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Fri, 28 Mar 2014 10:58:43 -0500 Subject: RFR for JDK-8038276 java/net/NetworkInterface/Test.java fails on windows intermittently for Teredo Interface In-Reply-To: <533558B9.1080009@oracle.com> References: <533503A6.3090503@oracle.com> <533558B9.1080009@oracle.com> Message-ID: <53359C33.8050603@oracle.com> Please sponsor this change . Thank you, Chris. Amanda On 3/28/14 6:10 AM, Chris Hegarty wrote: > Looks ok to me Amanda. I can sponsor this change, if needed. > > -Chris. > > On 28/03/14 05:07, Amanda Jiang wrote: >> Hi All , >> >> Please check and review following changes: >> http://cr.openjdk.java.net/~ewang/amanda/JDK-8038276/webrev.00/ >> >> Description of issue: >> Root Cause: >> Test java/net/NetworkInterface/Test.java failed because virtual >> interface "Teredo Tunneling Pseudo-Interface" on windows returned random >> addresses, we should not test on that interface. >> Suggested Fixes: >> Remove windows&&Teredo Interfaces from test. From yiming.wang at oracle.com Sun Mar 30 02:55:27 2014 From: yiming.wang at oracle.com (Eric Wang) Date: Sun, 30 Mar 2014 10:55:27 +0800 Subject: RFR for bug JDK-8025209 Intermittent test failure: java/net/Socket/asyncClose/AsyncClose.java In-Reply-To: <533551F6.2050909@oracle.com> References: <5316F2FE.5040501@oracle.com> <53350E97.6050205@oracle.com> <533551F6.2050909@oracle.com> Message-ID: <5337879F.10803@oracle.com> Hi Chris, I have updated the webrev according to your suggestions. Can you please review it again? http://cr.openjdk.java.net/~ewang/JDK-8025209/webrev.01/ Thanks to review the fix and sponsor it for me. -Eric On 2014/3/28 18:41, Chris Hegarty wrote: > Hi Eric, > > I've taken a look at the webrev and I mainly agree with the > changes/refactoring. > > On the issue of increasing the timeout to 20 secs; there is a clear > race in this test, and your refactoring has reduced it as much as > possible. Since the sleep will always occur, I would prefer to reduce > it from 20 secs to 5 secs. That, in combination with your use of a > latch, should be sufficient. > > Also, there is a variant of each test that runs with a 5,000 > millisecond timeout. This timeout should be increased to 20,000 > milliseconds. Otherwise, the blocking IO call may timeout rather than > be interrupted ( which is what the test is testing for ). > > If you address the above issues, I will be happy to sponsor this > change for you. > > -Chris. > > On 28/03/14 05:54, Eric Wang wrote: >> Hi Chris & All, >> >> Sorry that the fix spent a bit long time for internal review. >> Can you please review the fix below for bug JDK-8025209 >> . The fix is just to >> make the thread synchronization is more robust and made some cleanup. >> http://cr.openjdk.java.net/~ewang/JDK-8025209/webrev.00/ >> >> Thanks, >> Eric >> On 2014/3/5 18:01, Chris Hegarty wrote: >>> On 5 Mar 2014, at 09:48, Eric Wang wrote: >>> >>>> Hi everyone, >>>> >>>> Hi Everyone, >>>> >>>> I'm working on the test >>>> bughttps://bugs.openjdk.java.net/browse/JDK-8025209, The test uses >>>> Thread.sleep to sync-up threads which is not a correct assumption. >>>> The fix is just to sync-up 2 threads using proper way. >>>> >>>> The webrev will be sent after internal review. Please let me know >>>> if you have any comment. >>> This test is part of the OpenJDK source. Please just post your >>> webrev externally for review. >>> >>> Thanks, >>> -Chris. >>> >>>> Thanks, >>>> Eric >>>> >> From erik.joelsson at oracle.com Thu Mar 27 11:02:27 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 27 Mar 2014 12:02:27 +0100 Subject: RFR [9] 8038459: (sctp) Remove superflous classes on platforms without an implementation [macosx, aix] In-Reply-To: References: Message-ID: <53340543.50808@oracle.com> Looks good to me from a build perspective. /Erik On 2014-03-27 11:46, Chris Hegarty wrote: > While hunting around the build recently, when working on another SCTP bug, I noticed a small issue where SCTP classes are being built on some platforms unnecessarily. > > Webrev: > http://cr.openjdk.java.net/~chegar/8038459/webrev.00/webrev/ > > Mac OS X and AIX contain only stubs for the SCTP channels. There are platform specific versions of the stubs for these platforms, so the build currently filters out the three channel implementation classes, on these platforms. But, there are other implementation classes in src/solaris/classes/sun/nio/ch/sctp that are needed for Linux and Solaris. These classes should be filter out also, on platforms that do not require them ( Mac OS X and AIX ). > > Looking at rt. jar from a Mac JRE the superfluous classes can be seen: > > $ jar -tvf rt.jar | grep "sun/nio/ch/sctp" > 2420 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/AssociationChange.class <<< NOT NEEDED > 759 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/AssociationImpl.class <<< NOT NEEDED > 2614 Thu Feb 27 23:47:04 GMT 2014 sun/nio/ch/sctp/MessageInfoImpl.class > 2607 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/PeerAddrChange.class <<< NOT NEEDED > 2793 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/ResultContainer.class <<< NOT NEEDED > 2850 Thu Feb 27 23:47:10 GMT 2014 sun/nio/ch/sctp/SctpChannelImpl.class > 2987 Thu Feb 27 23:47:10 GMT 2014 sun/nio/ch/sctp/SctpMultiChannelImpl.class > 7712 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/SctpNet.class <<< NOT NEEDED > 251 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/SctpNotification.class <<< NOT NEEDED > 1935 Thu Feb 27 23:47:10 GMT 2014 sun/nio/ch/sctp/SctpServerChannelImpl.class > 1379 Thu Feb 27 23:47:04 GMT 2014 sun/nio/ch/sctp/SctpStdSocketOption.class > 1953 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/SendFailed.class <<< NOT NEEDED > 1239 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/Shutdown.class <<< NOT NEEDED > > Note: SctpStdSocketOption.class and MessageInfoImpl.class are platform independent, and needed to support parts of the API that are not dependent on an actual socket implementation. > > -Chris. From chris.hegarty at oracle.com Mon Mar 31 10:37:55 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 31 Mar 2014 11:37:55 +0100 Subject: RFR for bug JDK-8025209 Intermittent test failure: java/net/Socket/asyncClose/AsyncClose.java In-Reply-To: <5337879F.10803@oracle.com> References: <5316F2FE.5040501@oracle.com> <53350E97.6050205@oracle.com> <533551F6.2050909@oracle.com> <5337879F.10803@oracle.com> Message-ID: <53394583.3040407@oracle.com> Thanks Eric, Pushed http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e0d1a825848f There was a small issue of secs vs millis. Your webrev used 5 millis as a sleep rather than 5000. I fixed this before pushing. Also, with the changes the time for the test increased so I trivially added a change to have the various socket type checks run in parallel. With this the run time of the test is half of that of the original test. -Chris. On 30/03/14 03:55, Eric Wang wrote: > Hi Chris, > > I have updated the webrev according to your suggestions. Can you please > review it again? > http://cr.openjdk.java.net/~ewang/JDK-8025209/webrev.01/ > > Thanks to review the fix and sponsor it for me. > -Eric > > On 2014/3/28 18:41, Chris Hegarty wrote: >> Hi Eric, >> >> I've taken a look at the webrev and I mainly agree with the >> changes/refactoring. >> >> On the issue of increasing the timeout to 20 secs; there is a clear >> race in this test, and your refactoring has reduced it as much as >> possible. Since the sleep will always occur, I would prefer to reduce >> it from 20 secs to 5 secs. That, in combination with your use of a >> latch, should be sufficient. >> >> Also, there is a variant of each test that runs with a 5,000 >> millisecond timeout. This timeout should be increased to 20,000 >> milliseconds. Otherwise, the blocking IO call may timeout rather than >> be interrupted ( which is what the test is testing for ). >> >> If you address the above issues, I will be happy to sponsor this >> change for you. >> >> -Chris. >> >> On 28/03/14 05:54, Eric Wang wrote: >>> Hi Chris & All, >>> >>> Sorry that the fix spent a bit long time for internal review. >>> Can you please review the fix below for bug JDK-8025209 >>> . The fix is just to >>> make the thread synchronization is more robust and made some cleanup. >>> http://cr.openjdk.java.net/~ewang/JDK-8025209/webrev.00/ >>> >>> Thanks, >>> Eric >>> On 2014/3/5 18:01, Chris Hegarty wrote: >>>> On 5 Mar 2014, at 09:48, Eric Wang wrote: >>>> >>>>> Hi everyone, >>>>> >>>>> Hi Everyone, >>>>> >>>>> I'm working on the test >>>>> bughttps://bugs.openjdk.java.net/browse/JDK-8025209, The test uses >>>>> Thread.sleep to sync-up threads which is not a correct assumption. >>>>> The fix is just to sync-up 2 threads using proper way. >>>>> >>>>> The webrev will be sent after internal review. Please let me know >>>>> if you have any comment. >>>> This test is part of the OpenJDK source. Please just post your >>>> webrev externally for review. >>>> >>>> Thanks, >>>> -Chris. >>>> >>>>> Thanks, >>>>> Eric >>>>> >>> > From chris.hegarty at oracle.com Mon Mar 31 13:42:42 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 31 Mar 2014 14:42:42 +0100 Subject: RFR [9] 8038821: Fix typo; consructed to constructed Message-ID: <533970D2.3090501@oracle.com> Trivial typo fix. diff --git a/src/share/classes/java/net/HttpCookie.java b/src/share/classes/java/net/HttpCookie.java --- a/src/share/classes/java/net/HttpCookie.java +++ b/src/share/classes/java/net/HttpCookie.java @@ -74,7 +74,7 @@ private boolean httpOnly; // HttpOnly ... i.e. not accessible to scripts private int version = 1; // Version=1 ... RFC 2965 style - // The original header this cookie was consructed from, if it was + // The original header this cookie was constructed from, if it was // constructed by parsing a header, otherwise null. private final String header; @@ -985,7 +985,7 @@ } /* - * Returns the original header this cookie was consructed from, if it was + * Returns the original header this cookie was constructed from, if it was * constructed by parsing a header, otherwise null. */ private String header() { diff --git a/src/share/classes/sun/misc/JavaNetHttpCookieAccess.java b/src/share/classes/sun/misc/JavaNetHttpCookieAccess.java --- a/src/share/classes/sun/misc/JavaNetHttpCookieAccess.java +++ b/src/share/classes/sun/misc/JavaNetHttpCookieAccess.java @@ -36,7 +36,7 @@ public List parse(String header); /* - * Returns the original header this cookie was consructed from, if it was + * Returns the original header this cookie was constructed from, if it was * constructed by parsing a header, otherwise null. */ public String header(HttpCookie cookie); From yiming.wang at oracle.com Mon Mar 31 13:48:13 2014 From: yiming.wang at oracle.com (Eric Wang) Date: Mon, 31 Mar 2014 21:48:13 +0800 Subject: RFR for bug JDK-8025209 Intermittent test failure: java/net/Socket/asyncClose/AsyncClose.java In-Reply-To: <53394583.3040407@oracle.com> References: <5316F2FE.5040501@oracle.com> <53350E97.6050205@oracle.com> <533551F6.2050909@oracle.com> <5337879F.10803@oracle.com> <53394583.3040407@oracle.com> Message-ID: <5339721D.2030301@oracle.com> Hi Chris, Thanks for the push. I'm glad to learn the modern way from your refactor. - Cheers, Eric On 2014/3/31 18:37, Chris Hegarty wrote: > Thanks Eric, > > Pushed > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e0d1a825848f > > There was a small issue of secs vs millis. Your webrev used 5 millis > as a sleep rather than 5000. I fixed this before pushing. > > Also, with the changes the time for the test increased so I trivially > added a change to have the various socket type checks run in parallel. > With this the run time of the test is half of that of the original test. > > -Chris. > > > On 30/03/14 03:55, Eric Wang wrote: >> Hi Chris, >> >> I have updated the webrev according to your suggestions. Can you please >> review it again? >> http://cr.openjdk.java.net/~ewang/JDK-8025209/webrev.01/ >> >> Thanks to review the fix and sponsor it for me. >> -Eric >> >> On 2014/3/28 18:41, Chris Hegarty wrote: >>> Hi Eric, >>> >>> I've taken a look at the webrev and I mainly agree with the >>> changes/refactoring. >>> >>> On the issue of increasing the timeout to 20 secs; there is a clear >>> race in this test, and your refactoring has reduced it as much as >>> possible. Since the sleep will always occur, I would prefer to reduce >>> it from 20 secs to 5 secs. That, in combination with your use of a >>> latch, should be sufficient. >>> >>> Also, there is a variant of each test that runs with a 5,000 >>> millisecond timeout. This timeout should be increased to 20,000 >>> milliseconds. Otherwise, the blocking IO call may timeout rather than >>> be interrupted ( which is what the test is testing for ). >>> >>> If you address the above issues, I will be happy to sponsor this >>> change for you. >>> >>> -Chris. >>> >>> On 28/03/14 05:54, Eric Wang wrote: >>>> Hi Chris & All, >>>> >>>> Sorry that the fix spent a bit long time for internal review. >>>> Can you please review the fix below for bug JDK-8025209 >>>> . The fix is just to >>>> make the thread synchronization is more robust and made some cleanup. >>>> http://cr.openjdk.java.net/~ewang/JDK-8025209/webrev.00/ >>>> >>>> Thanks, >>>> Eric >>>> On 2014/3/5 18:01, Chris Hegarty wrote: >>>>> On 5 Mar 2014, at 09:48, Eric Wang wrote: >>>>> >>>>>> Hi everyone, >>>>>> >>>>>> Hi Everyone, >>>>>> >>>>>> I'm working on the test >>>>>> bughttps://bugs.openjdk.java.net/browse/JDK-8025209, The test uses >>>>>> Thread.sleep to sync-up threads which is not a correct assumption. >>>>>> The fix is just to sync-up 2 threads using proper way. >>>>>> >>>>>> The webrev will be sent after internal review. Please let me know >>>>>> if you have any comment. >>>>> This test is part of the OpenJDK source. Please just post your >>>>> webrev externally for review. >>>>> >>>>> Thanks, >>>>> -Chris. >>>>> >>>>>> Thanks, >>>>>> Eric >>>>>> >>>> >> From ivan.gerasimov at oracle.com Mon Mar 31 14:48:51 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 31 Mar 2014 18:48:51 +0400 Subject: RFR [9] 8038821: Fix typo; consructed to constructed In-Reply-To: <533970D2.3090501@oracle.com> References: <533970D2.3090501@oracle.com> Message-ID: <53398053.6010807@oracle.com> Hi Chris! Would it be good to include a couple more typo fixes in this change? diff --git a/src/share/classes/java/net/DatagramSocket.java b/src/share/classes/java/net/DatagramSocket.java --- a/src/share/classes/java/net/DatagramSocket.java +++ b/src/share/classes/java/net/DatagramSocket.java @@ -445,7 +445,7 @@ * *

If given an {@link InetSocketAddress InetSocketAddress}, this method * behaves as if invoking {@link #connect(InetAddress,int) connect(InetAddress,int)} - * with the the given socket addresses IP address and port number. + * with the given socket addresses IP address and port number. * * @param addr The remote address. * diff --git a/src/share/classes/java/net/InetAddress.java b/src/share/classes/java/net/InetAddress.java --- a/src/share/classes/java/net/InetAddress.java +++ b/src/share/classes/java/net/InetAddress.java @@ -159,7 +159,7 @@ *

*
networkaddress.cache.ttl
*
Indicates the caching policy for successful name lookups from - * the name service. The value is specified as as integer to indicate + * the name service. The value is specified as an integer to indicate * the number of seconds to cache the successful lookup. The default * setting is to cache for an implementation specific period of time. *

@@ -167,7 +167,7 @@ *

*
networkaddress.cache.negative.ttl (default: 10)
*
Indicates the caching policy for un-successful name lookups - * from the name service. The value is specified as as integer to + * from the name service. The value is specified as an integer to * indicate the number of seconds to cache the failure for * un-successful lookups. *

Sincerely yours, Ivan On 31.03.2014 17:42, Chris Hegarty wrote: > Trivial typo fix. > > diff --git a/src/share/classes/java/net/HttpCookie.java > b/src/share/classes/java/net/HttpCookie.java > --- a/src/share/classes/java/net/HttpCookie.java > +++ b/src/share/classes/java/net/HttpCookie.java > @@ -74,7 +74,7 @@ > private boolean httpOnly; // HttpOnly ... i.e. not accessible > to scripts > private int version = 1; // Version=1 ... RFC 2965 style > > - // The original header this cookie was consructed from, if it was > + // The original header this cookie was constructed from, if it was > // constructed by parsing a header, otherwise null. > private final String header; > > @@ -985,7 +985,7 @@ > } > > /* > - * Returns the original header this cookie was consructed from, > if it was > + * Returns the original header this cookie was constructed from, > if it was > * constructed by parsing a header, otherwise null. > */ > private String header() { > diff --git a/src/share/classes/sun/misc/JavaNetHttpCookieAccess.java > b/src/share/classes/sun/misc/JavaNetHttpCookieAccess.java > --- a/src/share/classes/sun/misc/JavaNetHttpCookieAccess.java > +++ b/src/share/classes/sun/misc/JavaNetHttpCookieAccess.java > @@ -36,7 +36,7 @@ > public List parse(String header); > > /* > - * Returns the original header this cookie was consructed from, > if it was > + * Returns the original header this cookie was constructed from, > if it was > * constructed by parsing a header, otherwise null. > */ > public String header(HttpCookie cookie); > > From chris.hegarty at oracle.com Mon Mar 31 14:59:12 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 31 Mar 2014 15:59:12 +0100 Subject: RFR [9] 8038821: Fix typo; consructed to constructed In-Reply-To: <53398053.6010807@oracle.com> References: <533970D2.3090501@oracle.com> <53398053.6010807@oracle.com> Message-ID: <533982C0.8050801@oracle.com> Thanks Ivan, I'll add them. -Chris. On 31/03/14 15:48, Ivan Gerasimov wrote: > Hi Chris! > > Would it be good to include a couple more typo fixes in this change? > > diff --git a/src/share/classes/java/net/DatagramSocket.java > b/src/share/classes/java/net/DatagramSocket.java > --- a/src/share/classes/java/net/DatagramSocket.java > +++ b/src/share/classes/java/net/DatagramSocket.java > @@ -445,7 +445,7 @@ > * > *

If given an {@link InetSocketAddress InetSocketAddress}, > this method > * behaves as if invoking {@link #connect(InetAddress,int) > connect(InetAddress,int)} > - * with the the given socket addresses IP address and port number. > + * with the given socket addresses IP address and port number. > * > * @param addr The remote address. > * > diff --git a/src/share/classes/java/net/InetAddress.java > b/src/share/classes/java/net/InetAddress.java > --- a/src/share/classes/java/net/InetAddress.java > +++ b/src/share/classes/java/net/InetAddress.java > @@ -159,7 +159,7 @@ > *

> *
networkaddress.cache.ttl
> *
Indicates the caching policy for successful name lookups from > - * the name service. The value is specified as as integer to indicate > + * the name service. The value is specified as an integer to indicate > * the number of seconds to cache the successful lookup. The default > * setting is to cache for an implementation specific period of time. > *

> @@ -167,7 +167,7 @@ > *

> *
networkaddress.cache.negative.ttl (default: 10)
> *
Indicates the caching policy for un-successful name lookups > - * from the name service. The value is specified as as integer to > + * from the name service. The value is specified as an integer to > * indicate the number of seconds to cache the failure for > * un-successful lookups. > *

> > Sincerely yours, > Ivan > > > On 31.03.2014 17:42, Chris Hegarty wrote: >> Trivial typo fix. >> >> diff --git a/src/share/classes/java/net/HttpCookie.java >> b/src/share/classes/java/net/HttpCookie.java >> --- a/src/share/classes/java/net/HttpCookie.java >> +++ b/src/share/classes/java/net/HttpCookie.java >> @@ -74,7 +74,7 @@ >> private boolean httpOnly; // HttpOnly ... i.e. not accessible >> to scripts >> private int version = 1; // Version=1 ... RFC 2965 style >> >> - // The original header this cookie was consructed from, if it was >> + // The original header this cookie was constructed from, if it was >> // constructed by parsing a header, otherwise null. >> private final String header; >> >> @@ -985,7 +985,7 @@ >> } >> >> /* >> - * Returns the original header this cookie was consructed from, >> if it was >> + * Returns the original header this cookie was constructed from, >> if it was >> * constructed by parsing a header, otherwise null. >> */ >> private String header() { >> diff --git a/src/share/classes/sun/misc/JavaNetHttpCookieAccess.java >> b/src/share/classes/sun/misc/JavaNetHttpCookieAccess.java >> --- a/src/share/classes/sun/misc/JavaNetHttpCookieAccess.java >> +++ b/src/share/classes/sun/misc/JavaNetHttpCookieAccess.java >> @@ -36,7 +36,7 @@ >> public List parse(String header); >> >> /* >> - * Returns the original header this cookie was consructed from, >> if it was >> + * Returns the original header this cookie was constructed from, >> if it was >> * constructed by parsing a header, otherwise null. >> */ >> public String header(HttpCookie cookie); >> >> > From bradford.wetmore at oracle.com Mon Mar 31 17:37:45 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 31 Mar 2014 10:37:45 -0700 Subject: RFR [9] 8038821: Fix typo; consructed to constructed In-Reply-To: <533982C0.8050801@oracle.com> References: <533970D2.3090501@oracle.com> <53398053.6010807@oracle.com> <533982C0.8050801@oracle.com> Message-ID: <5339A7E9.50804@oracle.com> Chris/Ivan's changes look good to me. Brad On 3/31/2014 7:59 AM, Chris Hegarty wrote: > Thanks Ivan, I'll add them. > > -Chris. > > On 31/03/14 15:48, Ivan Gerasimov wrote: >> Hi Chris! >> >> Would it be good to include a couple more typo fixes in this change? >> >> diff --git a/src/share/classes/java/net/DatagramSocket.java >> b/src/share/classes/java/net/DatagramSocket.java >> --- a/src/share/classes/java/net/DatagramSocket.java >> +++ b/src/share/classes/java/net/DatagramSocket.java >> @@ -445,7 +445,7 @@ >> * >> *

If given an {@link InetSocketAddress InetSocketAddress}, >> this method >> * behaves as if invoking {@link #connect(InetAddress,int) >> connect(InetAddress,int)} >> - * with the the given socket addresses IP address and port number. >> + * with the given socket addresses IP address and port number. >> * >> * @param addr The remote address. >> * >> diff --git a/src/share/classes/java/net/InetAddress.java >> b/src/share/classes/java/net/InetAddress.java >> --- a/src/share/classes/java/net/InetAddress.java >> +++ b/src/share/classes/java/net/InetAddress.java >> @@ -159,7 +159,7 @@ >> *

>> *
networkaddress.cache.ttl
>> *
Indicates the caching policy for successful name lookups from >> - * the name service. The value is specified as as integer to indicate >> + * the name service. The value is specified as an integer to indicate >> * the number of seconds to cache the successful lookup. The default >> * setting is to cache for an implementation specific period of time. >> *

>> @@ -167,7 +167,7 @@ >> *

>> *
networkaddress.cache.negative.ttl (default: 10)
>> *
Indicates the caching policy for un-successful name lookups >> - * from the name service. The value is specified as as integer to >> + * from the name service. The value is specified as an integer to >> * indicate the number of seconds to cache the failure for >> * un-successful lookups. >> *

>> >> Sincerely yours, >> Ivan >> >> >> On 31.03.2014 17:42, Chris Hegarty wrote: >>> Trivial typo fix. >>> >>> diff --git a/src/share/classes/java/net/HttpCookie.java >>> b/src/share/classes/java/net/HttpCookie.java >>> --- a/src/share/classes/java/net/HttpCookie.java >>> +++ b/src/share/classes/java/net/HttpCookie.java >>> @@ -74,7 +74,7 @@ >>> private boolean httpOnly; // HttpOnly ... i.e. not accessible >>> to scripts >>> private int version = 1; // Version=1 ... RFC 2965 style >>> >>> - // The original header this cookie was consructed from, if it was >>> + // The original header this cookie was constructed from, if it was >>> // constructed by parsing a header, otherwise null. >>> private final String header; >>> >>> @@ -985,7 +985,7 @@ >>> } >>> >>> /* >>> - * Returns the original header this cookie was consructed from, >>> if it was >>> + * Returns the original header this cookie was constructed from, >>> if it was >>> * constructed by parsing a header, otherwise null. >>> */ >>> private String header() { >>> diff --git a/src/share/classes/sun/misc/JavaNetHttpCookieAccess.java >>> b/src/share/classes/sun/misc/JavaNetHttpCookieAccess.java >>> --- a/src/share/classes/sun/misc/JavaNetHttpCookieAccess.java >>> +++ b/src/share/classes/sun/misc/JavaNetHttpCookieAccess.java >>> @@ -36,7 +36,7 @@ >>> public List parse(String header); >>> >>> /* >>> - * Returns the original header this cookie was consructed from, >>> if it was >>> + * Returns the original header this cookie was constructed from, >>> if it was >>> * constructed by parsing a header, otherwise null. >>> */ >>> public String header(HttpCookie cookie); >>> >>> >>