[concurrency-interest] ReentrantLock bug?

Dmitry Zaslavsky dmitry.zaslavsky at gmail.com
Fri Mar 20 13:43:22 EDT 2015

Was able to repro with 7u40

> On Mar 19, 2015, at 8:56 PM, David Holmes <davidcholmes at aapt.net.au> wrote:
> StackOverflow is know to cause the ReentrantLock to be left in an invalid state whereby it appears locked but is not. This can lead to hangs during classloading due to the use of ConcurrentHashMap for maintaining the classloading locks. The CHM implementation was changed (CHMv8) to use synchronized instead of ReentrantLock, and so this classloader issue does not affect JDK 8 or later. But of course ReentrantLock itself is still affected by this problem.
> There were some other fixes in the low-level park/unpark code that went into 7u40 (8004902) but they were found by code inspection not by anyone encountering the actual bug - as far as we know.
> David
>> -----Original Message-----
>> From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Dmitry Zaslavsky
>> Sent: Friday, 20 March 2015 6:53 AM
>> To: Vladimir Sitnikov
>> Cc: concurrency-interest
>> Subject: Re: [concurrency-interest] ReentrantLock bug?
>> I doubt it's one of those conditions.
>> I would expect the process to die but it's perfectly fine otherwise. Due to this issue it looks like a deadlocked process
>> Sent from mobile device
>> On Mar 19, 2015, at 4:50 PM, Vladimir Sitnikov <sitnikov.vladimir at gmail.com <mailto:sitnikov.vladimir at gmail.com>> wrote:
>>> I typically observe 'invalid' state of ReentrantLock due to StackOverflowError/OutOfMemoryError.
>>> Can you try your application with extended stack size and/or check for SOE/OOM?
>>> Regards,
>>> Vladimir Sitnikov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20150320/4c259438/attachment.html>

More information about the Concurrency-interest mailing list