Debug - Deadlock Detection [message #1748553] |
Thu, 24 November 2016 10:34 |
|
I have been dealing with a few deadlocks in my RCP application lately, and have been wondering why Eclipse is not able to tell me that a deadlock occurred and highlight the affected threads in the Debug View.
I have found this post [1] from 2007, which suggests there already is a deadlock detection in Eclipse. Has it been removed, or hidden somewhere?
Or does it just not work for my particular problem?
The deadlocks I've encountered all occurred because two threads synchronized on the same object. The first is the display thread, that wants to access the object, though the second already has the lock, and won't free it until it can run something synchronously in the display thread.
Now I can pause the process, unfold all threads, and I will find two instances of the same node "waiting for: org.eclipse.ui.internal.Semaphore (id=221)". The nodes above that reveal additional information about who owns the lock and who is waiting.
So even if there is no magic way to discover any kind of deadlock, wouldn't it be possible to automatically iterate over all tree items, and identify two Semaphores with the same ID, once the process is paused?
[1] https://runnerwhocodes.blogspot.de/2007/10/deadlock-detection-with-eclipse.html
|
|
|
|
Re: Debug - Deadlock Detection [message #1748622 is a reply to message #1748588] |
Fri, 25 November 2016 11:57 |
|
Quote:
If any of the blocking is done by other means (like some form of sync_exec, use of a semaphore...), then this cannot be recognized.
Then this is probably the case, though I don't understand why, because I synchronize using the "synchronized" keyword, and Display#syncExec does the same:
synchronized (Device.class) {
...
}
In any case, wouldn't it be feasible to detect additional deadlocks the way I have described above?
Quote:
[...] automatically iterate over all tree items, and identify two Semaphores with the same ID, once the process is paused
|
|
|
Powered by
FUDForum. Page generated in 0.03392 seconds