ReentrantLock bug?

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

ReentrantLock bug?

Dmitry Zaslavsky
Apologies for such a silly report / question.

    I have an application that out 100s of machines, every couple of runs would get into a state that’s only possible if ReentrantLock has a bug.
    While it would be hard to repro locally. On the grid it’s quite easy to repeat.
    Of course it’s possible I am doing something something very wrong.
    One time I saw RL in a locked state but the owner was null.
    I replaced all the uses of _lock.lock() try {} finally { _lock.unlock(); } with synchronized(_lock) and the problem went away.

   Still using jdk 7 u21
   Any suggestions?


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantLock bug?

Aleksey Shipilev-2
On 03/19/2015 11:02 PM, Dmitry Zaslavsky wrote:

> Apologies for such a silly report / question.
>
>     I have an application that out 100s of machines, every couple of runs would get into a state that’s only possible if ReentrantLock has a bug.
>     While it would be hard to repro locally. On the grid it’s quite easy to repeat.
>     Of course it’s possible I am doing something something very wrong.
>     One time I saw RL in a locked state but the owner was null.
>     I replaced all the uses of _lock.lock() try {} finally { _lock.unlock(); } with synchronized(_lock) and the problem went away.
>
>    Still using jdk 7 u21
>    Any suggestions?
The usual things:

 a) Update the JDK to at least 7u40 (or even better, JDK 8u40);
 b) -Xbootclasspath/p: the latest jsr166.jar (only works with JDK 8, I
think);

We have experimental RL tests in jcstress [1], you may want to try those
on your target machines.

-Aleksey.

[1]
http://hg.openjdk.java.net/code-tools/jcstress/file/5fcd4f948639/tests-custom/src/main/java/org/openjdk/jcstress/tests/locks



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantLock bug?

Vladimir Sitnikov

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


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantLock bug?

Dmitry Zaslavsky
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 <[hidden email]> 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


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantLock bug?

Dmitry Zaslavsky
In reply to this post by Aleksey Shipilev-2
I'll try asking for later jdk but it's not under my control :(

Would you happen to know of any relevant specific changes

Thanks

Sent from mobile device

> On Mar 19, 2015, at 4:32 PM, Aleksey Shipilev <[hidden email]> wrote:
>
>> On 03/19/2015 11:02 PM, Dmitry Zaslavsky wrote:
>> Apologies for such a silly report / question.
>>
>>    I have an application that out 100s of machines, every couple of runs would get into a state that’s only possible if ReentrantLock has a bug.
>>    While it would be hard to repro locally. On the grid it’s quite easy to repeat.
>>    Of course it’s possible I am doing something something very wrong.
>>    One time I saw RL in a locked state but the owner was null.
>>    I replaced all the uses of _lock.lock() try {} finally { _lock.unlock(); } with synchronized(_lock) and the problem went away.
>>
>>   Still using jdk 7 u21
>>   Any suggestions?
>
> The usual things:
>
> a) Update the JDK to at least 7u40 (or even better, JDK 8u40);
> b) -Xbootclasspath/p: the latest jsr166.jar (only works with JDK 8, I
> think);
>
> We have experimental RL tests in jcstress [1], you may want to try those
> on your target machines.
>
> -Aleksey.
>
> [1]
> http://hg.openjdk.java.net/code-tools/jcstress/file/5fcd4f948639/tests-custom/src/main/java/org/openjdk/jcstress/tests/locks
>
>

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantLock bug?

Dr Heinz M. Kabutz
In reply to this post by Dmitry Zaslavsky
Hi Dmitry,

is it possible to send me a sanitized stack trace of what state the
thread would be in if RL caused a hang?  Someone reported a very strange
behaviour a long time ago on Linux with JDK 7, where you could sometimes
get a thread that was waiting for a lock, even though it was Unlocked.  
The lock they used was a direct copy of ReentrantLock, with the only
difference being that it had been not been loaded in the system class
loader.  I managed to reproduce it, although not sure of the exact
version of Java 7.  After several day of chasing it, I ran out of time
and left it, but I've always had the niggling suspicion that it might be
a bug that lives fine and well in the ReentrantLock.

This was for Java 1.7.0_40, -server.  I thus do not share Aleksey's
optimism that moving over to that version is going to make the problem
go away.  I could not reproduce it on 1.8, but that might have just been
a coincidence.  It was quite difficult to reproduce.

BTW, not a silly report / question at all.  Very important indeed,
especially considering how many classes in JDK use ReentrantLock
internally :-(((

Regards

Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun/Oracle Java Champion since 2005
JavaOne Rock Star Speaker 2012
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz



Dmitry Zaslavsky wrote:

> Apologies for such a silly report / question.
>
>     I have an application that out 100s of machines, every couple of runs would get into a state that’s only possible if ReentrantLock has a bug.
>     While it would be hard to repro locally. On the grid it’s quite easy to repeat.
>     Of course it’s possible I am doing something something very wrong.
>     One time I saw RL in a locked state but the owner was null.
>     I replaced all the uses of _lock.lock() try {} finally { _lock.unlock(); } with synchronized(_lock) and the problem went away.
>
>    Still using jdk 7 u21
>    Any suggestions?
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>  
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantLock bug?

Dr Heinz M. Kabutz
The initial discovery was shown here: https://github.com/rafaelbrandao/msc

Regards

Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun/Oracle Java Champion since 2005
JavaOne Rock Star Speaker 2012
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz



Dr Heinz M. Kabutz wrote:

> Hi Dmitry,
>
> is it possible to send me a sanitized stack trace of what state the
> thread would be in if RL caused a hang?  Someone reported a very
> strange behaviour a long time ago on Linux with JDK 7, where you could
> sometimes get a thread that was waiting for a lock, even though it was
> Unlocked.  The lock they used was a direct copy of ReentrantLock, with
> the only difference being that it had been not been loaded in the
> system class loader.  I managed to reproduce it, although not sure of
> the exact version of Java 7.  After several day of chasing it, I ran
> out of time and left it, but I've always had the niggling suspicion
> that it might be a bug that lives fine and well in the ReentrantLock.
>
> This was for Java 1.7.0_40, -server.  I thus do not share Aleksey's
> optimism that moving over to that version is going to make the problem
> go away.  I could not reproduce it on 1.8, but that might have just
> been a coincidence.  It was quite difficult to reproduce.
>
> BTW, not a silly report / question at all.  Very important indeed,
> especially considering how many classes in JDK use ReentrantLock
> internally :-(((
>
> Regards
>
> Heinz
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantLock bug?

Vitaly Davidovich
Hmm, the symptoms seem very similar to the set of bugs (should've been fixed by 7u21 time though, AFAIR) that were filed due to missing barriers in the native Parker class.  In those cases, -XX:+UseMembar masked the problem and things worked -- has that been tried with the copy of RL?

Also, what exactly are the differences between the JDK RL and the "nearly unmodified" one?

On Thu, Mar 19, 2015 at 5:34 PM, Dr Heinz M. Kabutz <[hidden email]> wrote:
The initial discovery was shown here: https://github.com/rafaelbrandao/msc

Regards

Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun/Oracle Java Champion since 2005
JavaOne Rock Star Speaker 2012
http://www.javaspecialists.eu
Tel: <a href="tel:%2B30%2069%2075%20595%20262" value="+306975595262" target="_blank">+30 69 75 595 262
Skype: kabutz



Dr Heinz M. Kabutz wrote:
Hi Dmitry,

is it possible to send me a sanitized stack trace of what state the thread would be in if RL caused a hang?  Someone reported a very strange behaviour a long time ago on Linux with JDK 7, where you could sometimes get a thread that was waiting for a lock, even though it was Unlocked.  The lock they used was a direct copy of ReentrantLock, with the only difference being that it had been not been loaded in the system class loader.  I managed to reproduce it, although not sure of the exact version of Java 7.  After several day of chasing it, I ran out of time and left it, but I've always had the niggling suspicion that it might be a bug that lives fine and well in the ReentrantLock.

This was for Java 1.7.0_40, -server.  I thus do not share Aleksey's optimism that moving over to that version is going to make the problem go away.  I could not reproduce it on 1.8, but that might have just been a coincidence.  It was quite difficult to reproduce.

BTW, not a silly report / question at all.  Very important indeed, especially considering how many classes in JDK use ReentrantLock internally :-(((

Regards

Heinz
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantLock bug?

Dr Heinz M. Kabutz
I boiled it down to whether AQS was loaded in the boot class loader or not.  Go figure. But as I said, I ran out of time to look at it more. 

Heinz

On Friday, 20 March 2015, Vitaly Davidovich <[hidden email]> wrote:
Hmm, the symptoms seem very similar to the set of bugs (should've been fixed by 7u21 time though, AFAIR) that were filed due to missing barriers in the native Parker class.  In those cases, -XX:+UseMembar masked the problem and things worked -- has that been tried with the copy of RL?

Also, what exactly are the differences between the JDK RL and the "nearly unmodified" one?

On Thu, Mar 19, 2015 at 5:34 PM, Dr Heinz M. Kabutz <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;heinz@javaspecialists.eu&#39;);" target="_blank">heinz@...> wrote:
The initial discovery was shown here: https://github.com/rafaelbrandao/msc

Regards

Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun/Oracle Java Champion since 2005
JavaOne Rock Star Speaker 2012
http://www.javaspecialists.eu
Tel: <a href="tel:%2B30%2069%2075%20595%20262" value="+306975595262" target="_blank">+30 69 75 595 262
Skype: kabutz



Dr Heinz M. Kabutz wrote:
Hi Dmitry,

is it possible to send me a sanitized stack trace of what state the thread would be in if RL caused a hang?  Someone reported a very strange behaviour a long time ago on Linux with JDK 7, where you could sometimes get a thread that was waiting for a lock, even though it was Unlocked.  The lock they used was a direct copy of ReentrantLock, with the only difference being that it had been not been loaded in the system class loader.  I managed to reproduce it, although not sure of the exact version of Java 7.  After several day of chasing it, I ran out of time and left it, but I've always had the niggling suspicion that it might be a bug that lives fine and well in the ReentrantLock.

This was for Java 1.7.0_40, -server.  I thus do not share Aleksey's optimism that moving over to that version is going to make the problem go away.  I could not reproduce it on 1.8, but that might have just been a coincidence.  It was quite difficult to reproduce.

BTW, not a silly report / question at all.  Very important indeed, especially considering how many classes in JDK use ReentrantLock internally :-(((

Regards

Heinz
_______________________________________________
Concurrency-interest mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;Concurrency-interest@cs.oswego.edu&#39;);" target="_blank">Concurrency-interest@cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun/Oracle Java Champion
JavaOne Rockstar Speaker
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantLock bug?

David Holmes-6
In reply to this post by Dmitry Zaslavsky
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: [hidden email] [mailto:[hidden email]]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 <[hidden email]> 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


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantLock bug?

David Holmes-6
In reply to this post by Dr Heinz M. Kabutz
Hi Heinz,

By strange coincidence Martin Buchholz just uncovered a lost unpark problem involving the system classloader. See the later comments in:

https://bugs.openjdk.java.net/browse/JDK-8074773

David

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of Dr Heinz
> M. Kabutz
> Sent: Friday, 20 March 2015 7:17 AM
> To: Dmitry Zaslavsky
> Cc: [hidden email]
> Subject: Re: [concurrency-interest] ReentrantLock bug?
>
>
> Hi Dmitry,
>
> is it possible to send me a sanitized stack trace of what state the
> thread would be in if RL caused a hang?  Someone reported a very strange
> behaviour a long time ago on Linux with JDK 7, where you could sometimes
> get a thread that was waiting for a lock, even though it was Unlocked.  
> The lock they used was a direct copy of ReentrantLock, with the only
> difference being that it had been not been loaded in the system class
> loader.  I managed to reproduce it, although not sure of the exact
> version of Java 7.  After several day of chasing it, I ran out of time
> and left it, but I've always had the niggling suspicion that it might be
> a bug that lives fine and well in the ReentrantLock.
>
> This was for Java 1.7.0_40, -server.  I thus do not share Aleksey's
> optimism that moving over to that version is going to make the problem
> go away.  I could not reproduce it on 1.8, but that might have just been
> a coincidence.  It was quite difficult to reproduce.
>
> BTW, not a silly report / question at all.  Very important indeed,
> especially considering how many classes in JDK use ReentrantLock
> internally :-(((
>
> Regards
>
> Heinz
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun/Oracle Java Champion since 2005
> JavaOne Rock Star Speaker 2012
> http://www.javaspecialists.eu
> Tel: +30 69 75 595 262
> Skype: kabutz
>
>
>
> Dmitry Zaslavsky wrote:
> > Apologies for such a silly report / question.
> >
> >     I have an application that out 100s of machines, every
> couple of runs would get into a state that’s only possible if
> ReentrantLock has a bug.
> >     While it would be hard to repro locally. On the grid it’s
> quite easy to repeat.
> >     Of course it’s possible I am doing something something very wrong.
> >     One time I saw RL in a locked state but the owner was null.
> >     I replaced all the uses of _lock.lock() try {} finally {
> _lock.unlock(); } with synchronized(_lock) and the problem went away.
> >
> >    Still using jdk 7 u21
> >    Any suggestions?
> >
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > [hidden email]
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >  
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantLock bug?

Dmitry Zaslavsky
In reply to this post by David Holmes-6
Thanks for the info.
I neglected to mention, that I actually have a custom thread pool (borrowing heavily on fj and others :))
So threads would call park/unpark a lot more than just RL. I assumed it’s not an issue since can spuriously wake up anyways.
I will to try tomorrow on 7u40
Thanks again

On Mar 19, 2015, at 8:56 PM, David Holmes <[hidden email]> 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: [hidden email] [[hidden email]]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 <[hidden email]> 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


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantLock bug?

Kirk Pepperdine
In reply to this post by Dmitry Zaslavsky
I see app’s survive OOME because only the offending thread gets shot down. After the request that causes the OOME is shot down, the rest of the app works fine.. for some definition of fine.

Regards,
Kirk

On Mar 19, 2015, at 9:52 PM, Dmitry Zaslavsky <[hidden email]> wrote:

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 <[hidden email]> 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

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

signature.asc (507 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantLock bug?

Nathan Reynolds-2
I have hit this ReentrantLock issue a lot in the past.  Since I could prove anything about ReentrantLock, I didn't bother filing the bug.  Sorry.  My workaround was to switch over to synchronized.  I now avoid ReentrantLock.  It would be nice to get this fixed.
-Nathan
On 3/19/2015 11:04 PM, Kirk Pepperdine wrote:
I see app’s survive OOME because only the offending thread gets shot down. After the request that causes the OOME is shot down, the rest of the app works fine.. for some definition of fine.

Regards,
Kirk

On Mar 19, 2015, at 9:52 PM, Dmitry Zaslavsky <[hidden email]> wrote:

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 <[hidden email]> 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

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantLock bug?

Arcadiy Ivanov
Generally speaking, an application should not attempt to survive an OOME (except in rare cases of direct ByteBuffer allocation and other arguably controlled OOMEs). I believe even a synchronized monitor can get in the inconsistent state on OOME, if you're particularly unlucky that day. It's sort of like ThreadDeath error situation - once you get it is very hard to know if an application is in the consistent state.

On 2015-03-20 11:12, Nathan Reynolds wrote:
I have hit this ReentrantLock issue a lot in the past.  Since I could prove anything about ReentrantLock, I didn't bother filing the bug.  Sorry.  My workaround was to switch over to synchronized.  I now avoid ReentrantLock.  It would be nice to get this fixed.
-Nathan
On 3/19/2015 11:04 PM, Kirk Pepperdine wrote:
I see app’s survive OOME because only the offending thread gets shot down. After the request that causes the OOME is shot down, the rest of the app works fine.. for some definition of fine.

Regards,
Kirk

On Mar 19, 2015, at 9:52 PM, Dmitry Zaslavsky <[hidden email]> wrote:

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 <[hidden email]> 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

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantLock bug?

Dmitry Zaslavsky
In reply to this post by David Holmes-6
Was able to repro with 7u40

On Mar 19, 2015, at 8:56 PM, David Holmes <[hidden email]> 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: [hidden email] [[hidden email]]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 <[hidden email]> 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


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest