Community
Participate
Working Groups
Created attachment 207405 [details] deadlock backtrace Installed Features: org.eclipse.team.svn_0.7.9.I20110819-1700 org.polarion.eclipse.team.svn.connector_2.2.2.I20110819-1700 org.polarion.eclipse.team.svn.connector.svnkit15_2.2.2.I20110819-1700 org.polarion.eclipse.team.svn.connector.svnkit16_2.2.2.I20110819-1700 org.polarion.eclipse.team.svn.m2eclipse_1.0.2.I20110227-1700 Using the latest Indigo release (AFAICS), I get a deadlock every time I startup a certain workspace.
After careful consideration of the situation and the provided stacktraces the only conclusion is that there are no deadlocks. It seeme like some time consuming operation is in progress instead. The only related thing that comes to mind is that since the time of the report there were some performance improvements (related to the JDT support and refreshing resources) made in Subversive that probably (but no guarantee) could help the situation.
Can you explain why this isn't a deadlock? syncExec isn't processed during earlyStartup (which is where the main thread is). The result is: main thread (UI): holds UI ; trying to acquire ws lock Worker-0 : holds WS lock ; trying to syncExec onto the UI => Deadlock.
Note this may be a team issue, rather than a SVNKit issue. However if I have my history view at the top, and shutdown the WS, then I can't start the worskpace again. (A workaround is to delete the securestorage file, disabling the password prompt...)
The point is that the main thread awaits team provider being loaded, while team provider loading is stumbled upon a class loading and awaits for closing of the secure storage password prompt dialog called somewhere deep inside the Eclipse Platform class loader workflow (I do not understand why, since I know nothing of the Eclipse Platform class loader implementation). It means that IDE was locked not due to the Subversive code: public void start(BundleContext context) throws Exception { super.start(context); this.tracker = new ServiceTracker(context, IProxyService.class.getName(), null); // <---- locked here on class loading but due to class loader implementation. I could have tried to move this report somewhere else (Platform Component), but there are few other points present too: 1) There is a high chance somewhere around your visually "locked" Eclipse IDE instance was present a password prompt window, for whatever the reason it was called. 2) There are no threads in BLOCKED state. There are no cross-locks in Subversive (the only thread running Subversive code is worker-0, which is just plug-in startup) or Platform code. 3) On the other hand it seems there are at least two actively running IO streams (they're not in IO-wait mode), which could cause slow startup for the workspace. Considering all those reasons I've closed the report. P.S. It is definitely not the Subversive issue, but it does not seem as Team issue either. Also considering thread's states it does not seem like a "deadlock" issue at all. It more seems like "dialog opened behind the main window" issue.
Ok. I do understand how the eclipse platform and ui interact, and trust me this a real deadlock. Neither the main UIthread, nor the worker thread can make progress because they each require a resource held by the other, as outlined in my previous comment. The other threads are unimportant to the deadlock. Moving to platform as its history view and team.
(In reply to comment #5) Yes, I get what is it you're telling me. Looks like it'll be better for me to get a little more sleep time this week. :)
Created attachment 243321 [details] Testcase
I was about to log this bug. I'm experiencing a deadlock (well more specifically a "LiveLock") when the workbench starts up for an RCP application (version 4.3.2, but I think this problem exists in older version too) that I'm working on. It only happens on gtk and after debugging it I found the problem. org.eclipse.ui.application.WorkbenchAdvisor.java class has a method called: public boolean openWindows(){... } And this method tells the main method to fire off a thread to do work and call display.wake() when its done. In the meantime the main thread calls display.sleep() in while loop waiting for this thread to finish. The main thread never gets past this point ... because the "wake" signal was never picked up. looking in the sleep() method there is a comment: /* * Bug in GTK. For some reason, g_main_context_wakeup() may * fail to wake up the UI thread from the polling function. * The fix is to sleep for a maximum of 50 milliseconds. */ and what it does it resets the "wake" flag that was raised by the wake thread ... I've attached a small test class that will hopefully prove this livelock.
I have 2 workarounds: 1) Override that openWindows method and add a sleep just before the display.wake gets called in the thread. (1000ms ... it really sucks) 2) Start another rcp application instance to unstuck the first one ... (this sucks too)
Created attachment 243322 [details] My improved workaround Instead of the sleep workaround I now do the following to workaround the live lock
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This bug was marked as stalebug a while ago. Marking as wontfix. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag.
