Community
Participate
Working Groups
Quite at random (although it seems to be mostly on double clicks or right clicks) Eclipse will hang. Waiting a long time (~10 minutes) will cause it to finally revive. I've traced the problem back to gtk_clipboard_wait_for_contents() (which I see has caused issues in the past).
Created attachment 14687 [details] Java stack trace of locked Eclipse instance If you look at the [main] thread you will see we are stuck in gtk_clipboard_wait_for_contents. I've seen this issue many times.
Created attachment 14688 [details] C stack trace of hung Eclipse instance This is the C stack trace of the same instance of a hung Eclipse as is shown in the java stack trace. If you skip past the instructions Eclipse has used to suspend execution (the hung instance was running in the java debugger) you will see: #12 0x4da3cb8a in unblock_source () from /usr/lib/libglib-2.0.so.0 #13 0x4da3d9b5 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #14 0x4da3dd48 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #15 0x4da3e3ee in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #16 0x4d75d7de in gtk_clipboard_wait_for_contents ()
This can happen if the application which owns the clipboard is not responding. The clipboard in X is distributed, while SWT's clipboard API is synchronous. If the clipboard owner is being debugged or is otherwise suspended and unable to respond, Eclipse will hang waiting for the contents. It could also be that the clipboard owner is acting up. Are you running 'nedit'? It was found to be unhappy about returning clipboard contents (see the end of bug 70299). Are you running a clipboard manager such as KDE's 'klipper'?
I'm not running nedit, but I am running klippy. Could you expand on your statement: "The clipboard in X is distributed, while SWT's clipboard API is synchronous." Also, while the Eclipse instance from which I am reporting this problem is run under the Debugger from another Eclipse instance, it is NOT stopped until after the hang. So there is no suspended application that would cause this hang. I'd appreciate your assistance in trying to understand the issue likely causing this problem.
In X you send an event to the application that owns the clipboard and wait for a response. In GTK+ you use a callback: when you hit paste your application doesn't block, it just does something in the callback if it (ever) gets the results). My understanding is that SWT's API does not have callbacks for the clipboard results, it expects them to be available immediately. Hence, to satisfy this API, SWT uses gtk_clipboard_wait_for_contents to hang until it gets something (or GTK+ hits its timeout of ~10 minutes or so).
Since this sort of thing has come up in the past and I haven't found anything that does something similar, the following short C program will tell you who owns the clipboard. You can get a little more information about the window ID using 'xwininfo -id <value>'. I print the name, but it might not be the application main window that owns it. You can use 'xwininfo -tree -root' to find out what application owns it. http://vektor.ca/eclipse/xclipowner.c The compile line is at the top of the file. Please post who owns the clipboard when Eclipse hangs.
Created attachment 14693 [details] xwininfo -tree -root for the clipboard owner On a side note: you rock! Just got another hang. Here is the info you requested: tau.cisco.com:17> ~/xclipowner PRIMARY owner is 0x1a002ed (konsole) SECONDARY has no owner. CLIPBOARD owner is 0x140001b (klipper) tau.cisco.com:18> xwininfo -id 0x140001b xwininfo: Window id: 0x140001b "klipper" Absolute upper-left X: 397 Absolute upper-left Y: 342 Relative upper-left X: 397 Relative upper-left Y: 342 Width: 795 Height: 456 Depth: 24 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x28 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsUnMapped Override Redirect State: no Corners: +397+342 -398+342 -398-342 +397-342 -geometry 795x456+397+342 Output of xwininfo -tree -root is in the attachement. The primary owner is konsole is probably an artifact of me using konsole to run the xclipowner command from the konsole window.
Looks like a duplicate of bug 44915. Please see comment #8.
Should read: Please see bug 44915 comment #8.
You sure? That comment is for a dup that does not seem appropriate ...
Sorry, one last time. Should read: Please see bug 44915 comment #43.
Actually, I have read bug 44915 comment #43. I don't think thats the case here. The only reason I was running Eclipse under the debugger at all was because I'd seen the problem several times before. My senario was 1) Debug eclipse (call it B) from eclipse (call it A) 2) No breakpoints set at all. 3) Maximize B and work for some time (ie A is not in focus). 4) B hangs (usually on a double click or right click of some element). 5) Use A to pause execution of B to gather stack traces. 6) A is not hung. I don't see where this is related to bug 44915 comment #43 at all. Do you have any other thoughts on the problem? Any other data you'd like collected?
*** Bug 75633 has been marked as a duplicate of this bug. ***
I got the same problem and eclipse pretty much freezes every time I hit a breakpoint. I checked (using posted program and info) which app was owning the clipboard and I got different cases. First firefox was the one owning the clipboard. I closed it. I was then ok for a few breakpoints until I guessed I used the clipboard with something else. It then froze again and it seems the clipboard was owned by the gnome-panel. It is not as suggested earlier only because the debugged eclipse owns the clipboard. I am on a RedHat 9.0 with Ximian gtk installed is gtk2-2.2.4-0.ximian.6.2 Eclipse for Linux/GTK: Version: 3.0.1 Build id: 200409161125
Problem seems to no longer occur.
