[PATCH] 8035653: jdk8u152-b01 windows crash on DatagramSocket.getLocalAddress
Hi, We found that 8035653 test from jdk9 [1] crashes jdk8u152-b01 on windows at this point [2] because "ia6_class" is not initialized. It looks like the following bit of 8035653 is missed in jdk8u152-b01: diff -r 83726fe0f756 src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c --- a/src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c Tue Mar 21 17:08:03 2017 -0700 +++ b/src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c Wed Mar 22 23:18:30 2017 + @@ -87,6 +87,8 @@ IO_fd_fdID = NET_GetFileDescriptorID(env); CHECK_NULL(IO_fd_fdID); JNU_CHECK_EXCEPTION(env); + +initInetAddressIDs(env); } If it will be convenient, I can submit an issue+webrev and re-send this to jdk8u-dev list. But as 8u152 is not yet released and the fix is already in jdk9, I will appreciate some guidance on this problem. [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f6bf027e88e9/test/java/net/DatagramSocket/B8035653.java [2] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/83726fe0f756/src/share/native/java/net/net_util.c#l222 -- -Alex
Re: [PATCH] 8035653: jdk8u152-b01 windows crash on DatagramSocket.getLocalAddress
Hi Christoph, On 04/19/2017 10:53 AM, Langer, Christoph wrote: Hi Alex, I've just quickly checked this and it seems worthwile to me to downport 8035653 to JDK8. As the patch will probably not apply cleanly to JDK8 after unshuffling [1] , you will need to create a new public review and post it on this mailing list. Some JDK8 reviewer needs to review it and then you need to request approval for push into jdk8u-dev using this mail template [2]. After you've posted the webrev I can help you with the process. Generally, information about Java 8 backports can be found here: [3]. Thanks for your comments! I uploaded review [1] to downport 8035653 [2] to jdk8u/jdk8u-dev. Patch from jdk9/dev [3] does not apply cleanly, change to DualStackPlainDatagramSocketImpl.java was already added to jdk8 as part of 8072466 [4][5]. This patch brings changes to DualStackPlainDatagramSocketImpl.c and also includes B8035653.java test. [1] http://cr.openjdk.java.net/~akasko/jdk8u/8035653/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-8035653 [3] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8e5e92e0530e [4] https://bugs.openjdk.java.net/browse/JDK-8072466 [5] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/3623f1b29b58#l7.1 Best regards Christoph [1] http://cr.openjdk.java.net/~chegar/docs/portingScript.html [2] http://openjdk.java.net/projects/jdk8u/approval-template.html [3] http://openjdk.java.net/projects/jdk8u/ -Original Message- From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of Alex Kashchenko Sent: Donnerstag, 23. März 2017 00:51 To: net-dev@openjdk.java.net Subject: [PATCH] 8035653: jdk8u152-b01 windows crash on DatagramSocket.getLocalAddress Hi, We found that 8035653 test from jdk9 [1] crashes jdk8u152-b01 on windows at this point [2] because "ia6_class" is not initialized. It looks like the following bit of 8035653 is missed in jdk8u152-b01: diff -r 83726fe0f756 src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c --- a/src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c Tue Mar 21 17:08:03 2017 -0700 +++ b/src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c Wed Mar 22 23:18:30 2017 + @@ -87,6 +87,8 @@ IO_fd_fdID = NET_GetFileDescriptorID(env); CHECK_NULL(IO_fd_fdID); JNU_CHECK_EXCEPTION(env); + +initInetAddressIDs(env); } If it will be convenient, I can submit an issue+webrev and re-send this to jdk8u-dev list. But as 8u152 is not yet released and the fix is already in jdk9, I will appreciate some guidance on this problem. [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f6bf027e88e9/test/java/net/ DatagramSocket/B8035653.java [2] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/83726fe0f756/src/share/na tive/java/net/net_util.c#l222 -- -Alex -- -Alex
[11u] RFR: 8183369: RFC unconformity of HttpURLConnection with proxy
Hi, Please review the backport of JDK-8183369 to 11u: Bug: https://bugs.openjdk.java.net/browse/JDK-8183369 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/0ba758a2b6f0 11u webrev: http://cr.openjdk.java.net/~akasko/jdk11u/8183369/webrev.00/ Patch to HttpURLConnection applies cleanly, patch to HttpURLConWithProxy test was adjusted because mainline changes depend on JDK-8227539 that was added in 14. -- -Alex
Re: [11u] RFR: 8183369: RFC unconformity of HttpURLConnection with proxy
Hi Christoph, On 03/24/2020 12:36 PM, Langer, Christoph wrote: Hi Alex, I think this looks good overall. Thanks for the review! There's one line in test/jdk/java/net/HttpURLConnection/HttpURLConWithProxy.java, line 85, where you got the indentation wrong. Please check and fix that. Sorry for tabs on that line, not sure how they got there, updated webrev after :retab : http://cr.openjdk.java.net/~akasko/jdk11u/8183369/webrev.01/ Best regards Christoph -Original Message- From: jdk-updates-dev On Behalf Of Alex Kashchenko Sent: Dienstag, 24. März 2020 12:29 To: jdk-updates-...@openjdk.java.net Cc: net-dev@openjdk.java.net Subject: [11u] RFR: 8183369: RFC unconformity of HttpURLConnection with proxy Hi, Please review the backport of JDK-8183369 to 11u: Bug: https://bugs.openjdk.java.net/browse/JDK-8183369 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/0ba758a2b6f0 11u webrev: http://cr.openjdk.java.net/~akasko/jdk11u/8183369/webrev.00/ Patch to HttpURLConnection applies cleanly, patch to HttpURLConWithProxy test was adjusted because mainline changes depend on JDK-8227539 that was added in 14. -- -Alex -- -Alex
Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found
Hi,
Pinging politely about this issue.
I wonder whether it would be appropriate to file a CSR about
getJarFile() behaviour change at this point?
Concise description of the change is:
"So should the getJarFile return be a reference to JarFile for an URL
specifying an non existent entry i.e. the resource doesn't exist?"
On 04/02/2020 12:14 AM, mark sheppard wrote:
p.s.
I had also meant to say in the response below, that the proposed getJaFile
solution is
perfectly reasonable and would allow a recoverable strategy in an related
scenario where a URLConnection:: connect, for the same type of entry URL,
throws a FNFException resulting in the same type of "resource leak".
But, in this case, with the proposed change the JarFile can be retrieved and
closed.
regards
Mark
From: net-dev on behalf of mark sheppard
Sent: Wednesday 1 April 2020 16:03
To: Michael McMahon ; Alex Kashchenko
Cc: Mark Sheppard ; net-dev@openjdk.java.net >> OpenJDK
Network Dev list
Subject: Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when
file is not found
Hi Michael et al.,
just looking at the webrev ... the change in URLClassPath seems reasonable.
The change in JarURLConnection has implications and would change the semantics
of
the getJarFile method.
using the example accompanying this JBS item to demonstrate an issue caused by
the caching mechanism
within the URLConnection framework, it should be noted that the jar URL is
referencing
an non existent entry in the jar file entry. Thus some form of exception would
be anticipated in this scenario.
With the proposed change, this will return a JarFile regardless of whether a
referenced resource (URL) exists or not.
Examining the call flows it can be observed that
the getJarFile invokes connect. This will retrieve a jar file via JarFileFactory
and then, because the URL references an entry in the jar file, attempts
to access the entry resulting in a null return, which generates a FNF
exception to be thrown.
Also note that an explicit invocation of connect on the JarURLConnection
instance will result in the FNFException.
the change in the JarURLConnection will return a jar file in this test scenario
and not the FNF exception. Based on the methods
spec is that acceptable behaviour change?
public abstract JarFile getJarFile throws IOException
Return the JAR file for this connection.
Returns:
the JAR file for this connection. If the connection is a connection to an entry
of a JAR file, the JAR file object is returned
Throws:
IOException<https://docs.oracle.com/javase/7/docs/api/java/io/IOException.html>
- if an IOException occurs while trying to connect to the JAR file for this
connection.
See Also:
URLConnection.connect()<https://docs.oracle.com/javase/7/docs/api/java/net/URLConnection.html#connect()>
and connect says
"Opens a communications link to the resource referenced by this URL, if such a
connection has not already been established."
So should the getJarFile return be a reference to JarFile for an URL specifying
an non existent entry i.e. the resource doesn't exist?
Is the resource associated with a JarURLConnection the encapsulated JarFile? Or
the target in the specified in the URL ?
There are a series of similar behaviour anomalies in this area
URL/URLConnection/JarURLConnection (on Windows) and in general they
can be attributed to the internal caching mechanism, which is enabled OOTB,
and its impact on the closing of file resource in Exception conditions
scenarios.
Disabling caching for jar protocol , which will allow consistent and correct
behaviour is one possibility.
As such an alternative or workaround is to disable caching for the jar protocol
via the URLConnection::setDefaultUseCaches() on Windows where an application
may want to delete a jar file resource, for example:
URLConnection.setDefaultUseCaches("jar", false);
best regards
Mark
From: net-dev on behalf of Michael McMahon
Sent: Monday 16 March 2020 12:39
To: Alex Kashchenko
Cc: net-dev@openjdk.java.net >> OpenJDK Network Dev list
Subject: Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when
file is not found
Hi Alex,
(and redirecting the thread to net-dev)
It looks like a straight forward solution and perhaps the compatibility test
could be challenged on the basis of reliance on implementation behavior
rather than the spec.
But, more important I think is the behavior change of the fix itself and
that will require
careful review which we can't commit to immediately. We will try and get
back to you
about it in a week or so.
Thanks,
Michael.
On 14/03/2020 00:08, Alex Kashchenko wrote:
Hi,
Based on these maillist threads:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065076.html
https://mail.openjdk.java.net/pipermail/core-libs-dev/201
Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found
On 05/06/2020 01:11 PM, Michael McMahon wrote: Hi, Yes, we've had some discussion about it internally, and while others may yet have an opinion, I think this approach is a reasonable one, with a spec change that captures the behavior. The main thing we need to capture is that while connect() to a non existing resource may fail, getJarFile() can still return a reference to the containing JAR file if that is accessible. There could be other subtleties like what happens if the JAR file is not accessible, is null a reasonable return value in that case? I think that could happen and might need to be specified. I've created a CSR for this issue listing the "return null" variant above and "disable cache" as alternatives: https://bugs.openjdk.java.net/browse/JDK-8244650 The wording for getJarFile() specification currently doesn't specify what happens, when entry doesn't exist. If it is better to change this wording - I would appreciate a guidance on that. [...] -- -Alex
Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found
Thanks for your comments! On 05/08/2020 06:38 PM, Michael McMahon wrote: [...] https://bugs.openjdk.java.net/browse/JDK-8244650 I believe some sort of spec change will be needed, if only to justify challenging the JCK. Currently, the proposed change trips the following test: TestCase: [JarURLConnectionT216] FAIL->getManifest() did not throw expected IOException for jar:file:/JCK-runtime-15/tests/api/java_net/JarURLConnection//jardir/T11.jar!/NOJARENTRY.class I've added a reference to this failure to "Compatibility Risk Description". [...] I agree. Even though the @throws appears to say an IOException is only thrown if the connection to the JAR file fails, I think we should make it more explicit. Updated "Specification" part including the changes to the API spec. [...] -- -Alex
Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found
Hi, On 05/12/2020 12:20 AM, Alex Kashchenko wrote: CSR: https://bugs.openjdk.java.net/browse/JDK-8244650 A question about this CSR: after this new issue was found in the same area: JDK-8246714: URLClassLoader/JAR protocol handler poisons the global JarFile cache under concurrent load would it be appropriate to postpone the activity on the CSR (and possibly eventually cancel it)? It looks like both possible solutions to 8244650: - short term: disable caching for JAR protocol - long term: rework JAR protocol handler make this CSR redundant. I am happy to work on some minor bugfixes in this area if necessary. [...] -- -Alex
Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found
On 06/10/2020 03:52 PM, Alex Kashchenko wrote: Hi, On 05/12/2020 12:20 AM, Alex Kashchenko wrote: CSR: https://bugs.openjdk.java.net/browse/JDK-8244650 A question about this CSR: after this new issue was found in the same area: JDK-8246714: URLClassLoader/JAR protocol handler poisons the global JarFile cache under concurrent load would it be appropriate to postpone the activity on the CSR (and possibly eventually cancel it)? It looks like both possible solutions to 8244650: Correction to issue number: "both possible solutions to new issue JDK-8246714" - short term: disable caching for JAR protocol - long term: rework JAR protocol handler make this CSR redundant. I am happy to work on some minor bugfixes in this area if necessary. [...] -- -Alex
Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found
Hi, CSR: https://bugs.openjdk.java.net/browse/JDK-8244650 On 06/13/2020 10:49 PM, mark sheppard wrote: Hi, For JDK-8132359 it now addresses the issue: Amend JarURLConnection::getJarFile() to return JarFile object reference for nonexistent JAR file entry URL The scenario addressed is that a JarURLConnection is constructed encapsulating a reference to an non existent entry in an extant JarFile, then the getJarFile is reasonably expected to return a reference to the associated JarFile, rather than propagating the IOException thrown by the implicit JarURLConnection::connect invocation in getJarFile. The original test case demonstrates other cross platform issues in this context. But by returning the JarFile reference, ( rather than propagating the exception,) it is then possible to invoke close on the JarFile, and allow the explicit delete of the JarFile. Thus, mitigating a perceived problem on Windows. As such, this is an issue in its own right, and as such it would appear that there is merit in this fix. Thanks for your comments! Would it be appropriate to move the CSR to "Proposed" [1] at this point? [...] [1] https://wiki.openjdk.java.net/display/csr/Main#Main-CSRWorkflows -- -Alex
Re: [11u] RFR: 8232854: URLClassLoader.close() doesn't close cached JAR file on Windows when load() fails
Hi, On 3/1/20, Alex Kashchenko wrote: > Hi, > > Please review the fix to JDK-8232854 for 11u: > > Jira issue: https://bugs.openjdk.java.net/browse/JDK-8232854 > > Webrev: http://cr.openjdk.java.net/~akasko/jdk11u/8232854/webrev.00/ > > Patch is implemented based on a test code included with the Jira issue. > It fixes the case, when URLClassLoader is created with URL, that stars > with "jar:file:" and ends with non-root path inside JAR like > "foo.jar!/somedir/". > > Codepath in this case includes URLClassPath.Loader class, that requires > special handling when resources are loaded from a JAR file. Issue with > closing JAR file (on classloader close) on this codepath was previously > fixed in JDK-6896088: > > Jira issue: https://bugs.openjdk.java.net/browse/JDK-6896088 > > Changeset: http://hg.openjdk.java.net/jdk/jdk/rev/3af394bb6f59 > > This fix is complementary to 6896088, it is filling the "jarfile" field > in URLClassPath.Loader class (to be able to close the JAR file later) in > case, when requested resource failed to be loaded from this JAR. Note, > that getJarFile() on URLConnection to original resource cannot be used > in this case, because this method checks that requested resource is > valid. URLConnection to the root URL in this JAR is used instead. > > There probably exist more elegant solutions to this problem. This patch > is fix-only and should not affect any existing logic in URLClassPath. > > Test included with this fix is similar to > java/net/URLClassLoader/B6896088.java test. It uses specific JAR > structure (with a classfile inside "somedir" directory that is not a > part of class package) and checks JAR file closing after both successful > and failed load attempts. Test fails on Windows without this patch, on > Linux it always passes. Please review this updated fix to JDK-8232854 for 11u: Jira issue: https://bugs.openjdk.java.net/browse/JDK-8232854 Webrev: https://cr.openjdk.java.net/~akasko/jdk11u/8232854/webrev.01/ More broad fix to the underlying problem was discussed for jdk-latest [1][2][3]. It is proposed to proceed with this narrow point fix for jdk11 (and then jdk8). Updated patch was taken from this email sent by Rob McKenna [4]. Comparing with the patch originally proposed in webrev.00: code change to URLClassPath.java is equivalent, RemoveJar.java test is more thorough. Testing: checked that included test fails on Windows without the patch and passes with it (on Linux it always passes), ran relevant parts of JCK. [1] https://mail.openjdk.java.net/pipermail/net-dev/2020-April/013756.html [2] https://mail.openjdk.java.net/pipermail/net-dev/2020-May/013884.html [3] https://mail.openjdk.java.net/pipermail/net-dev/2020-June/014058.html [4] https://mail.openjdk.java.net/pipermail/net-dev/2019-November/013341.html -- -Alex
Re: RFR: 8270290: NTLM authentication fails if HEAD request is used
Hi, On 8/13/21, Michael McMahon wrote: > Hi, > > A question about this issue. Can you explain why the server/proxy is > sending a response body to a HEAD request? > > My reading of the RFCs suggests this is not allowed. Thanks for your comment and sorry for the late reply. To put aside the question about the support for non-compliant proxy servers, consider the scenario with HTTPS tunneling where proxy server never sees the HEAD request (it receives CONNECT). Please see the following abridged interaction where HEAD request is initiated from java code to HTTPS host some.hostname.com with proxy enabled: Transmission Control Protocol, Src Port: 53335, Dst Port: 8080, Seq: 1, Ack: 1, Len: 185 Hypertext Transfer Protocol CONNECT some.hostname.com:443 HTTP/1.1\r\n User-Agent: Java/1.8.0_302\r\n Host: some.hostname.com\r\n Proxy-Connection: keep-alive\r\n \r\n Transmission Control Protocol, Src Port: 8080, Dst Port: 53335, Seq: 7245, Ack: 186, Len: 413 Hypertext Transfer Protocol HTTP/1.1 407 Proxy Authentication Required\r\n Proxy-Authenticate: NTLM\r\n Proxy-Connection: close\r\n Connection: close\r\n Content-Length: 7384\r\n \r\n File Data: 7384 bytes Line-based text data: text/html (39 lines) \r\n [...] Transmission Control Protocol, Src Port: 53336, Dst Port: 8080, Seq: 1, Ack: 1, Len: 281 Hypertext Transfer Protocol CONNECT some.hostname.com:443 HTTP/1.1\r\n User-Agent: Java/1.8.0_302\r\n Host: some.hostname.com\r\n Proxy-Connection: keep-alive\r\n Proxy-authorization: NTLM TlRM[...]\r\n \r\n Transmission Control Protocol, Src Port: 8080, Dst Port: 53336, Seq: 7245, Ack: 282, Len: 690 Hypertext Transfer Protocol HTTP/1.1 407 Proxy Authentication Required\r\n Proxy-Authenticate: NTLM TlRM[...]\r\n Proxy-Connection: Keep-Alive\r\n Connection: Keep-Alive\r\n Content-Length: 7401\r\n \r\n File Data: 7401 bytes Line-based text data: text/html (39 lines) \r\n [...] Transmission Control Protocol, Src Port: 53336, Dst Port: 8080, Seq: 282, Ack: 7935, Len: 781 Hypertext Transfer Protocol CONNECT some.hostname.com:443 HTTP/1.1\r\n User-Agent: Java/1.8.0_302\r\n Host: some.hostname.com\r\n Proxy-Connection: keep-alive\r\n Proxy-authorization: NTLM TlRML[...]\r\n \r\n Transmission Control Protocol, Src Port: 8080, Dst Port: 53336, Seq: 7935, Ack: 1063, Len: 39 Hypertext Transfer Protocol HTTP/1.1 200 Connection established\r\n \r\n In this case the response code from "200 Connection established" response cannot be read by jdk because response body from the last CONNECT response was not fully read from the socket, jdk master will fail with the following trace: java.util.NoSuchElementException at java.base/java.util.StringTokenizer.nextToken(StringTokenizer.java:347) at java.base/sun.net.www.protocol.http.HttpURLConnection.doTunneling0(HttpURLConnection.java:2191) [...] This can be reproduced running NTLMHeadTest.java with TUNNEL argument. SERVER and PROXY modes were added to the test for completeness, it may be better to remove them. > > [...] > >> PR: https://git.openjdk.java.net/jdk/pull/4753 > -- -Alex
Re: RFR: 8270290: NTLM authentication fails if HEAD request is used
On 8/23/21, Alex Kashchenko wrote: > Hi, > > On 8/13/21, Michael McMahon wrote: >> Hi, >> >> A question about this issue. Can you explain why the server/proxy is >> sending a response body to a HEAD request? >> >> My reading of the RFCs suggests this is not allowed. > > Thanks for your comment and sorry for the late reply. To put aside the > question about the support for non-compliant proxy servers, consider > the scenario with HTTPS tunneling where proxy server never sees the > HEAD request (it receives CONNECT). Please see the following abridged > interaction where HEAD request is initiated from java code to HTTPS > host some.hostname.com with proxy enabled: > > [...] > > This can be reproduced running NTLMHeadTest.java with TUNNEL argument. > SERVER and PROXY modes were added to the test for completeness, it may > be better to remove them. A note on non-tunnel behaviour, I've reexamined its logic and found out that proposed patch breaks plain HTTP proxying (and server auth too) for HEAD requests, because the socket read in reset() [1] is blocking, and it blocks indefinitely for non-tunnel usage. The original problem is still valid for tunneling, I suggest to narrow the fix for tunneling only, will update the PR. [1] https://github.com/openjdk/jdk/blob/8973867fb9568a3a527b763c9ce10cebdfb306d0/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L2989 > >> >> [...] >> >>> PR: https://git.openjdk.java.net/jdk/pull/4753 >> -- -Alex
