Community
Participate
Working Groups
Created attachment 243754 [details] Deadlock trace If one of the Transfer subclasses, like URLTransfer, is loaded and initialized from a non-UI thread, it can cause a deadlock on Linux GTK. See bug 436002 for this happening with the Eclipse Marketplace Client. The deadlock is caused by two things (well, obviously ;-)): One being the class initialization of URLTransfer (but any other Transfer subclass would do, too) on a non-UI thread. This will statically register the transfer's types, which ultimately reaches OS.g_utf16_to_utf8() where it tries to get the SWT platform lock held by the main UI thread at the time. The second is another class (in our case Mylyn's Task List view) trying to use the same Transfer class on the UI thread. This cannot progress, because the class initialization is still going on on the other thread, which can't complete due to the lock held on the UI thread. Deadlock. Now, it's usually a safe bet that anything SWT should happen on the UI thread. In this instance though, the trigger is the loading and initialization of the URLTransfer (or any other Transfer) class, which can happen very easily and with little control - possibly even without intent - from just about any thread. For bug 436002 we've resolved this in MPC by moving the code causing the initialization back onto the UI thread. But I think SWT should either make this path safe to call from any thread or protect against it being called from a non-UI thread.
I believe this is happening for svn synchronize also. If this is the same issue I think this is a showstopper bug. I have had to revert back to 4.3. Whether I try to go to the Marketplace or try to do svn synchronize the app starts the process and then completely locks up. I have to force kill it to continue. Without svn and marketplace there is no way to use Eclipse. This is on a Cinnamon / gtk linux machine running Fedora 19. It seems that if this is a gtk / swt / luna issue then no one will be able to use that configuration. I vote this is a P1 Critical and needs an immediate hotfix -- but that's just because I want to be able to use the 4.4 release...
(In reply to Geoff Ruscoe from comment #1) > I believe this is happening for svn synchronize also. If this is the same > issue I think this is a showstopper bug. I have had to revert back to 4.3. > > Whether I try to go to the Marketplace or try to do svn synchronize the app > starts the process and then completely locks up. I have to force kill it to Geoff, can you please attach stack traces for the SVN lock? Thanks.
Geoff, this shouldn't be happening for Marketplace in the release (see bug 436002). If it happens at some point when opening the Marketplace Client, it's most likely not related to this issue. And I would assume that the SVN freeze is something different, too. To be sure, could you provide stack dumps of the frozen instances? See https://wiki.eclipse.org/How_to_report_a_deadlock#Getting_a_stack_trace_on_other_platforms for how to do that.
oops, what Dani said ;)
Created attachment 244737 [details] jstack when using svn -- status shows initializing compare edi... So I did a synchronize and then double clicked on a file to look at the changes. Sorry my original description was wrong. jstack was taken with the -l. Please let me know if you need a different version of the stack trace.
Created attachment 244738 [details] Opened Eclipse Market Place and it hangs The Marketplace dialog opens and the progress bar runs across and then disappears like it is going to show a new progress indication and then nothing happens. This stack trace is made with jstack without the -l, please let me know if you would like the stack trace created differently.
Those are definitely separate issues from the dnd Transfer problem in this bug. Looks like some problem with SWT and GTK3. I've opened bug 438755 for the MPC one. The SVN one seems to involve svnkit and Gnome integration. Maybe switching to JavaHL might help? I've opened bug 438760 for that one.
Oops, accidentally removed Geoff from cc
(In reply to Carsten Reckord from comment #0) > > If one of the Transfer subclasses, like URLTransfer, is loaded and > initialized from a non-UI thread, it can cause a deadlock on Linux GTK. > SWT should either make this path safe to call from any thread or protect > against it being called from a non-UI thread. I agree that the scenario described by you could cause a potential deadlock in SWT code but I only saw this bug now, sorry about that! Is there any real manifestation of this problem that we're aware of currently (other than the one fixed in MPC)? Do you happen to have any SWT only snippet of code that actually demonstrates the deadlock happening? I'll plan to investigate a proper fix in 4.6 with a chance to backport to 4.5.1 as any changes for this fix might mean change in existing behavior, and its probably not the right time to do that in RC builds IMO.
Sort of vaguely related... Bug 461767 - Add an unsynchronized Display.isDisplayThread() method
We are not able to look at this problem in 4.6. Need help from community in fixing the problem in 4.7
Moving out of 4.7.
Moving to 4.9, please re-target as required.
Resetting target, please re-target as required.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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.
