CODEWITHSUNDEEP
javaeclipsedeadlockreentrantreadwritelock
Scheintod
Scheintod

Reputation: 8105

Debugging ReentrantReadWriteLock Deadlock in Eclipse

I've got an Application which occasionally deadlocks (say once a month).

Right now I managed for the first time to reproduce this condition while running in eclipse debugger.

It seems as if all threads are waiting for the WriteLock to get released.

What I need is a way to find out which one (of the 200) Threads is holding the lock.

But pausing the threads in eclipse and inspecting has yielded no results because eclipse tells me it can't access the variables I want to view because the thread was manually suspended.

I don't want to restart the application because I don't know if I can manage to get into this deadlock a second time.

So what to do to find the lock holder?

EDIT: I've already tried jstack to make me a thread dump. But I can only find threads waiting for the lock but none holding it.

Upvotes: 1

Views: 373

Answers (1)

Taylor Smock
Taylor Smock

Reputation: 36

The problem here is that we need to get the application to hit a "normal" breakpoint.

There are a few different ways to do this. In all cases, the new breakpoint should pause the entire program (IntelliJ can do this, and I would assume Eclipse can as well).

  • Object#wait (method entry breakpoint on public final native void wait (long timeout))
  • Unsafe#;park (method entry breakpoint on public native void park(boolean isAbsolute, long time))
  • If you have a thread that is constantly performing work (e.g. getting remote data), add a breakpoint in that code

Once that has occurred, you can (in IntelliJ IDEA, and presumably Eclipse) switch threads to the threads of interest and debug from there.

In IntelliJ IDEA, I was able to do the following:

final Thread ownerThread = ((ReentrantReadWriteLock.WriteLock) lock.writeLock()).sync.getExclusiveOwnerThread();

Upvotes: 0

Related Questions