RFR 8240902: JDI shared memory connector can use already closed Handles

Patricio Chilano patricio.chilano.mateo at oracle.com
Tue Mar 17 20:14:14 UTC 2020


Hi all,

Please review the following patch:

Bug: https://bugs.openjdk.java.net/browse/JDK-8240902
Webrev: http://cr.openjdk.java.net/~pchilanomate/8240902/v1/webrev/

Calling closeConnection() on an already created/opened connection 
includes calls to CloseHandle() on objects that can still be used by 
other threads. This can lead to either undefined behavior or, as 
detailed in the bug comments, changes of state of unrelated objects. 
This issue was found while debugging the reason behind some jshell test 
failures seen after pushing 8230594. Not as important, but there are 
also calls to closeStream() from createStream()/openStream() when 
failing to create/open a stream that will return after executing 
"CHECK_ERROR(enterMutex(stream, NULL));" without closing the intended 
resources. Then, calling closeConnection() could assert if the reason of 
the previous failure was that the stream's mutex failed to be 
created/opened. These patch aims to address these issues too.

Tested in mach5 with the current baseline, tiers1-3 and several runs of 
open/test/langtools/:tier1 which includes the jshell tests where this 
connector is used. I also applied patch 
http://cr.openjdk.java.net/~pchilanomate/8240902/triggerbug/webrev 
mentioned in the comments of the bug, on top of the baseline and run the 
langtool tests with and without this fix. Without the fix running around 
30 repetitions already shows failures in tests 
jdk/jshell/FailOverExecutionControlTest.java and 
jdk/jshell/FailOverExecutionControlHangingLaunchTest.java. With the fix 
I run several hundred runs and saw no failures. Let me know if there is 
any additional testing I should do.

As a side note, I see there are a couple of open issues related with 
jshell failures (8209848) which could be related to this bug and 
therefore might be fixed by this patch.

Thanks,
Patricio



More information about the serviceability-dev mailing list