-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8256818: SSLSocket that is never bound or connected leaks socket resources #1363
Conversation
👋 Welcome back clanger! A progress list of the required criteria for merging this PR into |
@RealCLanger The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
I changed the check for when to do duplexClose to only do it when socket isConnected(). I also added a testcase which should work on all platforms. For windows I borrowed some functionality introduced lately with test java/lang/ProcessBuilder/checkHandles/CheckHandles.java which I moved to the test library for that reason. Now it's ready to review. |
Webrevs
|
Ping... Any takers? comments? reviews? |
I will have a look at this update. |
if ((fds_end - fds_start) > (NUM_TEST_SOCK / 10)) { | ||
throw new RuntimeException("Too many open file descriptors. Looks leaky."); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test case may be not reliable if there are some other test cases or applications running at the same time. It's a good manual test, but might be not suitable for OpenJDK automation regression test if it could be impacted.
* @summary Test that creating and closing SSL Sockets without bind/connect | ||
* will not leave leaking socket file descriptors | ||
* @library /test/lib | ||
* @run main/othervm SSLSocketLeak |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See bellow comment, I may suggest to have it as a manual test case if you agree the test case could be impacted.
@run main/manual SSLSocketLeak
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I think it's fine as it is. Running it in othervm will make sure the test runs in its own vm (see http://openjdk.java.net/jtreg/command-help.html). So within the VM process there should not be any interference by other workload. And we check open files before testing and afterwards, and allow for some margin.
The test has been running in our test setup for several days now, so I think it should be ok. And if worst comes to worse, and we see test noise, we might change the test to manual later on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me. Thanks!
@RealCLanger This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 182 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
/integrate |
@RealCLanger Since your change was applied there have been 182 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 93b6ab5. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
There is a flaw in sun.security.ssl.SSLSocketImpl::close() which leads to leaking socket resources after JDK-8224829.
The close method calls duplexCloseOutput() and duplexCloseInput(). In case of an exception in any of these methods, the call to closeSocket() is bypassed, and the underlying Socket may not be closed.
This manifests in a real life leak after JDK-8224829 has introduced a call to getSoLinger() on the path of duplexCloseOutput -> closeNotify. If socket impl / OS socket hadn't been created yet it is done at that place. But then after duplexCloseOutput eventually fails with a SocketException since the socket wasn't connected, closing fails to call Socket::close().
This problem can be reproduced by this code:
SSLSocket sslSocket = (SSLSocket)SSLSocketFactory.getDefault().createSocket();
sslSocket.getSSLParameters();
sslSocket.close();
This is what happens when SSLContext.getDefault().getDefaultSSLParameters() is called, with close() being eventually called by the finalizer.
I'll open this PR as draft for now to start discussion. I'll create a testcase to reproduce the issue and add it soon.
I propose to modify the close method such that duplexClose is only done on a connected/bound socket. Maybe it even suffices to only do it when connected.
Secondly, I'm proposing to improve exception handling a bit. So in case there's an IOException on the path of duplexClose, it is caught and logged. But the real close moves to the finally block since it should be done unconditionally.
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jdk pull/1363/head:pull/1363
$ git checkout pull/1363