RFR 8072466: Deadlock when starting MulticastSocket and DatagramSocket

Ivan Gerasimov ivan.gerasimov at oracle.com
Sat Sep 5 14:25:18 UTC 2015

Hi everyone!

The fix didn't bring enough attention back in February for some reason.
So, I'd like to re-request a review.

I've added a regression test, which reliably reproduces a deadlock on my 
local Windows 7 machine.

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8072466
WEBREV: http://cr.openjdk.java.net/~igerasim/8072466/00/webrev/

Sincerely yours,

On 17.02.2015 9:54, Ivan Gerasimov wrote:
> Can someone help review this fix please?
> Comments/suggestions are welcome!
> Sincerely yours,
> Ivan
> On 06.02.2015 20:48, Ivan Gerasimov wrote:
>> Hello!
>> There has been a deadlock in jdk-net code noticed on Windows.
>> In the bug description there's a stack snippet showing that one of 
>> the deadlocked threads stuck in the native initialization code of 
>> DualStackPlainDatagramSocketImpl and the other -- in initializing of 
>> TwoStacksPlainDatagramSocketImpl.
>> I suspect that the reason might be due to unordered initialization:
>> AbstractPlainDatagramSocketImpl, the parent of both classes above, 
>> explicitly loads TwoStacksPlainDatagramSocketImpl from the native 
>> init().
>> Thus, when both classes are being initialized concurrently, it may 
>> end with a clash.
>> Another issue noticed by Mark Sheppard is that the Windows version of 
>> DefaultDatagramSocketImplFactory.createDatagramSocketImpl() isn't 
>> synchronized, but reads/modifies shared data.
>> Thus, I removed modification and declared all the accessed fields final.
>> Would you please help review the proposed fix?
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8072466
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8072466/0/webrev/
>> The build went fine on all the platforms, all the tests from 
>> (net|nio|io) passed Okay.
>> Sincerely yours,
>> Ivan

More information about the core-libs-dev mailing list