[concurrency-interest] ReentrantReadWriteLock in inconsistent state

Nathan Reynolds nathan.reynolds at oracle.com
Thu Aug 2 13:59:41 EDT 2012


One other thought is that you are running on 6 Update 25.  6 Update 33 
and 7 Update 5 are available.  You might try running on those JVM and 
hope that the problem was fixed.

You might also try changing the -server/-client flag.

Nathan Reynolds 
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
Consulting Member of Technical Staff | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
On 8/1/2012 8:14 AM, Stanimir Simeonoff wrote:
> The usual case for that is... Thread.stop().
>         protected final boolean tryRelease(int releases) {
> .....
>                 setExclusiveOwnerThread(null);
> ---right here---
>                 setState(nextc);
> ....
>                 return true;
> }
>
> Cheers
> Stanimir
> On Wed, Aug 1, 2012 at 4:20 PM, Phil Harvey <phil at philharveyonline.com 
> <mailto:phil at philharveyonline.com>> wrote:
>
>     We had a deadlock-like failure of our application recently.
>
>     I initially reported it on the BDB JE forum (
>     https://forums.oracle.com/forums/thread.jspa?messageID=10480988)
>     but further analysis of the heap and thread dumps has exposed a
>     problem that looks like a Java locking bug. I'm hoping you can
>     offer advice on whether this is the case.
>
>     We're using Oracle JVM 1.6.0_25-b06, running on Linux version:
>     2.6.18-194.32.1.el5.
>
>     We are launching Java as follows: java -server
>     -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m ...
>
>     Several consecutive thread dumps showed that Thread t at 41101 was
>     blocked indefinitely in ReentrantReadWriteLock. writeLock().lock().
>
>     We know from code inspection that nothing ever takes a read lock
>     on this ReentrantReadWriteLock, so started trying to find out what
>     has got its write lock.
>
>     The output of "jstack -l" should list which thread holds this
>     exclusive lock in the "locked ownable synchronizers" section but
>     does not.
>
>     Our first theory was that the owning thread might have terminated.
>
>     We wrote a simple test program to explore this. We found from heap
>     dump analysis that even if the owning thread terminates, the lock
>     itself still refers to it via the
>     ReentrantReadWriteLock.WriteLock.sync. exclusiveOwnerThread field.
>     Looking in the java.util.concurrent source code, it seems that
>     this field only gets null'ed when the lock is released.
>
>     However, looking in the heap dump taken following our "deadlock",
>     we were surprised to find that the lock in question has a null
>     sync.exclusiveOwnerThread field.
>
>     Surely a write lock should be in one of two states (except
>     possibly for a tiny instant when its state is being non-atomically
>     switched):
>
>     1) The lock is available, and sync.exclusiveOwnerThread is null 2)
>     The lock is unavailable, and sync.exclusiveOwnerThread is populated
>
>     But our lock was indefinitely in this state:
>
>     3) The lock is unavailable and sync.exclusiveOwnerThread is null
>
>     Does anyone know whether this represents a bug? If not, can you
>     explain what it means for a lock to be in this counterintuitive state?
>
>     Thanks, Phil
>
>
>     _______________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.oswego.edu
>     <mailto:Concurrency-interest at cs.oswego.edu>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120802/9ab8cb38/attachment-0001.html>


More information about the Concurrency-interest mailing list