Comment 1 Steve Northover 2008-07-24 14:48:13 EDT

This one is really interesting.  Note that the event loops are stacked.  Can you get a repeatable case?

Comment 2 Bogdan Gheorghe 2008-07-24 16:46:34 EDT

Need some repro steps here to proceed.

Comment 3 James Blackburn 2008-07-24 16:48:32 EDT

(In reply to comment #2)
> Need some repro steps here to proceed.

I'm afraid I'm not sure how it happened.  I think I was changing from an external editor back to Eclipse and it hung.  I wasn't doing anything more exciting than that...

Comment 4 Francis Upton IV 2008-08-26 00:17:19 EDT

Steve, I got me a repeatable case on this.  Happens on a 3.4 system.  

It waits for 30 seconds and then continues.  The test case is simple, run the org.eclipse.ui.tests.navigator tests (see the one launch configuration, just run  that) on a Linux/GTK system.  They should normally take just a few seconds, but you will see a 30 second pause in one of the tests.

This happens on my Fedora 9 System just about every time.  When I run the single test in isolation, it does not have the delay.

Thread [main] (Suspended)	
	OS._gtk_clipboard_wait_for_contents(int, int) line: not available [native method]	
	OS.gtk_clipboard_wait_for_contents(int, int) line: 4199	
	Clipboard.gtk_clipboard_wait_for_contents(int, int) line: 617	
	Clipboard.getContents(Transfer, int) line: 293	
	Clipboard.getContents(Transfer) line: 240	
	PasteAction$1.run() line: 191	
	UISynchronizer(Synchronizer).syncExec(Runnable) line: 178	
	UISynchronizer.syncExec(Runnable) line: 150	
	Display.syncExec(Runnable) line: 4021	
	PasteAction.updateSelection(IStructuredSelection) line: 186	
	PasteAction(BaseSelectionListenerAction).selectionChanged(IStructuredSelection) line: 124	
	EditActionGroup.updateActionBars() line: 149	
	EditActionGroup.fillActionBars(IActionBars) line: 95	
	EditActionProvider.fillActionBars(IActionBars) line: 46	
	NavigatorActionService.initialize(String, CommonActionProvider) line: 359	
	NavigatorActionService.getActionProviderInstance(CommonActionProviderDescriptor) line: 339	
	NavigatorActionService.fillActionBars(IActionBars) line: 236	
	CommonNavigatorManager.selectionChanged(SelectionChangedEvent) line: 220	
	Viewer$2.run() line: 162	
	SafeRunner.run(ISafeRunnable) line: 37	
	Platform.run(ISafeRunnable) line: 880	
	JFaceUtil$1.run(ISafeRunnable) line: 48	
	SafeRunnable.run(ISafeRunnable) line: 175	
	CommonViewer(Viewer).fireSelectionChanged(SelectionChangedEvent) line: 160	
	CommonViewer(StructuredViewer).updateSelection(ISelection) line: 2062	
	CommonViewer(StructuredViewer).setSelection(ISelection, boolean) line: 1638	
	CommonViewer(TreeViewer).setSelection(ISelection, boolean) line: 1104	
	CommonViewer.setSelection(ISelection, boolean) line: 327	
	CommonViewer(Viewer).setSelection(ISelection) line: 392	
	ProgrammaticOpenTest.testNavigatorRootContents() line: 50	
	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
	Method.invoke(Object, Object...) line: 597	
	ProgrammaticOpenTest(TestCase).runTest() line: 164	
	ProgrammaticOpenTest(TestCase).runBare() line: 130	
	TestResult$1.protect() line: 106	
	TestResult.runProtected(Test, Protectable) line: 124	
	TestResult.run(TestCase) line: 109	
	ProgrammaticOpenTest(TestCase).run(TestResult) line: 120	
	TestSuite.runTest(Test, TestResult) line: 230	
	TestSuite.run(TestResult) line: 225	
	NavigatorTestSuite(TestSuite).runTest(Test, TestResult) line: 230	
	NavigatorTestSuite(TestSuite).run(TestResult) line: 225	
	JUnit3TestReference.run(TestExecution) line: 130	
	TestExecution.run(ITestReference[]) line: 38	
	RemotePluginTestRunner(RemoteTestRunner).runTests(String[], String, TestExecution) line: 460	
	RemotePluginTestRunner(RemoteTestRunner).runTests(TestExecution) line: 673	
	RemotePluginTestRunner(RemoteTestRunner).run() line: 386	
	RemotePluginTestRunner.main(String[]) line: 62	
	UITestApplication$1.run() line: 114	
	RunnableLock.run() line: 35	
	UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133	
	Display.runAsyncMessages(boolean) line: 3378	
	Display.readAndDispatch() line: 3036	
	Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 2382	
	Workbench.runUI() line: 2346	
	Workbench.access$4(Workbench) line: 2198	
	Workbench$5.run() line: 493	
	Realm.runWithDefault(Realm, Runnable) line: 288	
	Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 488	
	PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149	
	IDEApplication.start(IApplicationContext) line: 113	
	UITestApplication.start(IApplicationContext) line: 46	
	EclipseAppHandle.run(Object) line: 193	
	EclipseAppLauncher.runApplication(Object) line: 110	
	EclipseAppLauncher.start(Object) line: 79	
	EclipseStarter.run(Object) line: 382	
	EclipseStarter.run(String[], Runnable) line: 179	
	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
	Method.invoke(Object, Object...) line: 597	
	Main.invokeFramework(String[], URL[]) line: 549	
	Main.basicRun(String[]) line: 504	
	Main.run(String[]) line: 1236	
	Main.main(String[]) line: 1212	

Comment 5 Samantha Chan 2012-06-04 11:43:22 EDT

I am running on Eclipse 3.7.2.

I am marking this as major as I can reproduce this consistently at Eclipse startup.  Here's how I can reproduce this:
1.  I have my own Transfer, and I copied some data before shutting down Eclipse.
2.  In my editor, my paste action listens for selection event, and checks the clipboard content to update enable/disable state.
3.  When I start up Eclipse again, the paste action is called on a selection changed event.  At this time, it tries to get the clipboard content to see if it should be enabled.  Eclipse always hangs with the following stacktrace.

Is there a way around this problem?  

Thread [main] (Suspended)	
	owns: RunnableLock  (id=1990)	
	OS._gtk_clipboard_wait_for_contents(long, long) line: not available [native method]	
	OS.gtk_clipboard_wait_for_contents(long, long) line: 6293	
	Clipboard.gtk_clipboard_wait_for_contents(long, long) line: 646	
	Clipboard.getContents(Transfer, int) line: 294	
	Clipboard.getContents(Transfer) line: 241	
	PasteFromClipboardEmfCommand.getContentFromClipboard() line: 196	
	PasteFromClipboardEmfCommand.checkclipboardContent() line: 153	
	PasteFromClipboardEmfCommand.canExecute() line: 147	
	GraphEditorPasteAction(CommandActionHandler).updateSelection(IStructuredSelection) line: 105	
	GraphEditorPasteAction(BaseSelectionListenerAction).selectionChanged(IStructuredSelection) line: 124	
	GraphEditorPasteAction(BaseSelectionListenerAction).selectionChanged(SelectionChangedEvent) line: 137	
	Viewer$2.run() line: 164	
	SafeRunner.run(ISafeRunnable) line: 42	
	JFaceUtil$1.run(ISafeRunnable) line: 49	
	SafeRunnable.run(ISafeRunnable) line: 175	
	GraphViewer(Viewer).fireSelectionChanged(SelectionChangedEvent) line: 162	
	GraphViewer.access$9(GraphViewer, SelectionChangedEvent) line: 1	
	GraphViewer$2$1.runInUIThread(IProgressMonitor) line: 481	
	UIJob$1.run() line: 95	
	RunnableLock.run() line: 35	
	UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 135	
	Display.runAsyncMessages(boolean) line: 3563	
	Display.readAndDispatch() line: 3212	
	Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 2696	
	Workbench.runUI() line: 2660	
	Workbench.access$4(Workbench) line: 2494	
	Workbench$7.run() line: 674	
	Realm.runWithDefault(Realm, Runnable) line: 332	
	Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 667	
	PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149	
	IDEApplication.start(IApplicationContext) line: 123	
	EclipseAppHandle.run(Object) line: 196	
	EclipseAppLauncher.runApplication(Object) line: 110	
	EclipseAppLauncher.start(Object) line: 79	
	EclipseStarter.run(Object) line: 344	
	EclipseStarter.run(String[], Runnable) line: 179	
	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 60	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 37	
	Method.invoke(Object, Object...) line: 611	
	Main.invokeFramework(String[], URL[]) line: 622	
	Main.basicRun(String[]) line: 577	
	Main.run(String[]) line: 1410	
	Main.main(String[]) line: 1386

Comment 6 Martin Oberhuber 2013-09-20 11:47:15 EDT

CQ:WIND00435513

A customer sees Eclipse hanging up to 20 minutes (!) occasionally, with a stack trace also pointing to 
org.eclipse.swt.internal.gtk.OS._gtk_clipboard_wait_for_contents(Native Method)

This is with Eclipse 3.8.1 on 
Red Hat Enterprise Linux Server release 6.4 (Santiago)

The full stacktrace is from under Common Navigator, it looks like a click into the CN initiates an "update selection" which recomputes menu enablement and to check the enablement of the "Paste" action it calls _gtk_clipboard_wait_for_contents where it hangs. I could share the full stacktrace if it helps.

FYI, probably related bugs:

This one has a small c program that prints the clipboard owner, might help diagnosing such problems
https://bugs.eclipse.org/bugs/show_bug.cgi?id=74498#c6

That one is about clipboard invalid contents:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=273400

Comment 7 Martin Oberhuber 2013-12-18 20:23:20 EST

Our customer requires a fix for this problem, so we are willing to contribute code here. But we'll need a little bit guidance.

Our customer uses eXceed / XRDP. The problem occurs when they enable Clipboard Sharing between Windows and Linux: Eclipse hangs on the Linux side, trying to check the clipboard. When they disable clipboard sharing, they cannot reproduce the problem.

Customer says that no other Linux / GTK application has the problem like Eclipse. It looks like the GTK libraries somehow have a problem with the shared Windows Clipboard. 

- Is it possible that GTK API's are not quite properly called here ?
  Customer uses "gtk2-2.18.9-12.el6.i686". Running Eclipse in 32-bit mode
  on an x86_64 system (RHEL 6.4). This is with Eclipse 3.8.1 ... would any
  newer Eclipse probably work better here ? Any new SWT (GTK3) ?
- Would it make sense to implement a watchdog that interrupts the main Thread
  after a reasonable timeout (couple seconds) ? 
- Is any similar workaround (watchdog) in place at Eclipse anywhere ?

Comment 8 Arun Thondapu 2014-01-16 07:00:04 EST

(In reply to Martin Oberhuber from comment #7)
> 
> - Is it possible that GTK API's are not quite properly called here ?
>   Customer uses "gtk2-2.18.9-12.el6.i686". Running Eclipse in 32-bit mode
>   on an x86_64 system (RHEL 6.4). This is with Eclipse 3.8.1 ... would any
>   newer Eclipse probably work better here ? Any new SWT (GTK3) ?

I would recommend trying with a newer version of Eclipse like 4.2.2 or 4.3 and confirm whether the same issue is seen at your end. There have been a lot of changes in SWT since Eclipse 3.8 and its possible this problem could have got fixed.

Sravan, can you please check whether this problem is reproducible with Eclipse 4.4 or 4.3 on an RHEL machine while connecting from Windows?

> - Would it make sense to implement a watchdog that interrupts the main Thread
>   after a reasonable timeout (couple seconds) ? 
> - Is any similar workaround (watchdog) in place at Eclipse anywhere ?

As far as I'm aware, there is no workaround of this kind in Eclipse as this is not a widely seen or easily reproducible problem. I don't think we'll add such a workaround unless we can reproduce the issue at our end and figure out the root cause of the problem, if there is any and confirm the need for a fix. Thanks!

Comment 9 Sravan Kumar Lakkimsetti 2014-01-20 05:51:22 EST

(In reply to Arun Thondapu from comment #8)

> Sravan, can you please check whether this problem is reproducible with
> Eclipse 4.4 or 4.3 on an RHEL machine while connecting from Windows?

I tried to reproduce with the latest eclipse I am not able to reproduce this problem

Comment 10 Martin Oberhuber 2014-01-23 15:26:56 EST

Our customers can still reproduce this problem on RHEL 6.4 ,
with Eclipse SDK 4.4m4 32-bit running on Oracle Java 1.6.0_45.

Open Text Exceed – Exceed for X64 was used for accessing the Linux machine:
http://connectivity.opentext.de/contact/request-a-trial-version.aspx

The version of eXceed that I used was 14.0.10.647.  I launched Eclipse with java version 1.6.0_45, created a text file, highlighted and pasted text to the file and from other files as well as windows, then started right clicking in the GUI as part of this process.  After a couple minutes of this, Eclipse hung.  I verified this by starting jconsole and checking to see the stack trace for the main thread and verified that it was waiting for the clipboard.  Be sure that auto copy to and from the X clipboard is enabled in Exceed to test this.


Our customer also tried reproducing the problem with XRDP, but with mixed succes; using XRDP 0.5 , the issue was reproducable with a commercial product on top of Eclipse 3.8 , but not with Eclipse 4.4m4.

We'll be happy to help in any way we can, to nail down this issue and get it resolved. Our customers claim that no other Linux application other than Eclipse exhibits the "clipboard hang" problem. This is an annoyance that's blocking rollout and adoption of Eclipse.

Thanks!
Martin

Comment 11 Sravan Kumar Lakkimsetti 2014-01-23 23:07:50 EST

(In reply to Martin Oberhuber from comment #10)
> Our customers can still reproduce this problem on RHEL 6.4 ,
> with Eclipse SDK 4.4m4 32-bit running on Oracle Java 1.6.0_45.
> 
> Open Text Exceed – Exceed for X64 was used for accessing the Linux machine:
> http://connectivity.opentext.de/contact/request-a-trial-version.aspx
> 
> The version of eXceed that I used was 14.0.10.647.  I launched Eclipse with
> java version 1.6.0_45, created a text file, highlighted and pasted text to
> the file and from other files as well as windows, then started right
> clicking in the GUI as part of this process.  After a couple minutes of
> this, Eclipse hung.  I verified this by starting jconsole and checking to
> see the stack trace for the main thread and verified that it was waiting for
> the clipboard.  Be sure that auto copy to and from the X clipboard is
> enabled in Exceed to test this.
> 
> 
> Our customer also tried reproducing the problem with XRDP, but with mixed
> succes; using XRDP 0.5 , the issue was reproducable with a commercial
> product on top of Eclipse 3.8 , but not with Eclipse 4.4m4.
> 
> We'll be happy to help in any way we can, to nail down this issue and get it
> resolved. Our customers claim that no other Linux application other than
> Eclipse exhibits the "clipboard hang" problem. This is an annoyance that's
> blocking rollout and adoption of Eclipse.
> 
> Thanks!
> Martin

Thank you Martin for update. We will continue to investigate.

Comment 12 Arun Thondapu 2014-01-30 09:12:52 EST

(In reply to Sravan Kumar Lakkimsetti from comment #9)
> (In reply to Arun Thondapu from comment #8)
> 
> > Sravan, can you please check whether this problem is reproducible with
> > Eclipse 4.4 or 4.3 on an RHEL machine while connecting from Windows?
> 
> I tried to reproduce with the latest eclipse I am not able to reproduce this
> problem

Sravan, what are the versions of Java and Exceed you were using to test? May be we should try with the same versions as reported in comment 10.

Martin, we're trying to do what we can for fixing this bug but it is very difficult to debug or investigate without being able to actually reproduce the problem consistently and reliably.

Comment 13 Sravan Kumar Lakkimsetti 2014-02-10 00:34:12 EST

(In reply to Arun Thondapu from comment #12)
> (In reply to Sravan Kumar Lakkimsetti from comment #9)
> > (In reply to Arun Thondapu from comment #8)
> > 
> > > Sravan, can you please check whether this problem is reproducible with
> > > Eclipse 4.4 or 4.3 on an RHEL machine while connecting from Windows?
> > 
> > I tried to reproduce with the latest eclipse I am not able to reproduce this
> > problem
> 
> Sravan, what are the versions of Java and Exceed you were using to test? May
> be we should try with the same versions as reported in comment 10.
> 
> Martin, we're trying to do what we can for fixing this bug but it is very
> difficult to debug or investigate without being able to actually reproduce
> the problem consistently and reliably.

I have tested this on eclipse 4.4M4. But I used exceed on Demand 7(internal version is 13). using this I am not able to reproduce the problem (I had Xclipboard enabled). But I am not able to reproduce the problem reported. but I encountered a different problem.

Copying from windows to linux is working initially. but once you copy some text on the linux. copying across the XDMCP connection is broken in both directions from Windows to linux and linux to windows.

regarding the Exceed 14, We cannot get a version since it is a commercial product and also we cannot get evaluation version since it may infringe licensing terms.

Comment 14 Anton Leherbauer 2014-03-21 09:20:38 EDT

I also tried with eXceed and ran into the hang exactly once, but I think it is not that relevant in which configuration the hang occurs.
To me the symptoms match exactly those of bug 44915 comment 43, i.e. if the current clipboard owner is unresponsive, any access to the clipboard contents will freeze the IDE.
A simple reproducible scenario is e.g.
- open gedit and copy some text to the clipboard
- attach gdb to gedit to suspend it (or kill -STOP)
- try to paste into an Eclipse Text Editor (or select something in the Project Explorer)
-> hang

The GTK timeout in this case is 30 seconds, but as gtk_clipboard_wait_for_contents is often called multiple times in a row (e.g. for different transfer types) and as one usually tries to click repeatedly when the UI does not respond, the perceived timeouts can be much longer.

The only real fix would be to change from the synchronous gtk_clipboard_wait_for_contents to the asynchronous gtk_clipboard_request_contents, but this seems out of scope as it would require clients to adapt to an asynchronous API as well.

Therefore, I would suggest a simple workaround to at least limit the waiting time to 30 seconds:
- detect the timeout in Clipboard.gtk_clipboard_wait_for_contents
- in case of a timeout take the clipboard ownership by setting some dummy text into the clipboard
- subsequent calls won't timeout again

Comment 15 Martin Oberhuber 2014-03-23 03:57:17 EDT

Thanks for the detailed analysis, Toni !

Most important, we know know about a test case that's easily reproducible by anyone (make an app like gedit offer a clipboard, and then suspend that app).

I am not sure if a 30 sec timeout will be acceptable to our customers in the error case ... what do the SWT experts think, is any other solution in scope ?

Our customers mentioned that no other application except Eclipse exhibits the clipboard hang. Could that be because all other apps use the asynchronous gtk_clipboard_request_contents() ? Can we find out any statistics of who uses one versus the other ?

Comment 16 Martin Oberhuber 2014-04-15 18:08:46 EDT

Ping, any input from the SWT team now that we have a reproducable test case ?

Just to recap, this issue is a real annoyance since on some Linux systems Eclipse occasionally just hangs for minutes.

Comment 17 Martin Oberhuber 2014-05-07 10:45:59 EDT

Discussed this on the Eclipse Platform PMC:

- GTK developers recommend using the asynchronous API
- But switching syncronous SWT API to asynchronous implementation underneath
  is very dangerous and messy
- Given that the issue affects only few clients and only rarely, suggestion
  is to go with Toni's proposed approach (when timeout is detected, take
  clipboard ownership to avoid waiting > 30 seconds).

Is there any chance reducing the 30sec initial GTK timeout to eg 10 seconds ?
Having the project explorer hang 30sec will still be perceived as defective, although it is an improvement over hanging for minutes.

Comment 18 Martin Oberhuber 2014-05-18 20:54:35 EDT

While we have reproduced the clipboard hang by "stopping" a program that owns the clipboard, there might actually be a chance that in real life this problem is a variant of what Andrey Loskutov has analyzed here:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=205678#c11

What got me thinking is, that in real life the problem only occurs on some X servers. When Eclipse is at risk of mis-interpreting Clipboard contents with some X servers as Andrey described (particularly x11vnc has been reported), this mis-interpretation might lead to all kinds of odd behavior.

Comment 19 Anton Leherbauer 2014-05-28 07:23:01 EDT

I pushed a patch to gerrit with the partial solution outlined in comment 14.
https://git.eclipse.org/r/27439

Comment 20 Arun Thondapu 2014-08-27 10:05:01 EDT

(In reply to Anton Leherbauer from comment #19)
> I pushed a patch to gerrit with the partial solution outlined in comment 14.
> https://git.eclipse.org/r/27439

Thanks for the gerrit patch Anton! I've reviewed and tested the workaround and it does help in reducing the freeze time of Eclipse drastically... the patch has now been committed to both 4.5 and 4.4.1 streams.

http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=60ff4c61f9b274f470c47d2955baafd01620b5ee

http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R4_4_maintenance&id=d13ccd6ef4a4095ac499546efd950f93f593394c

I'm going to mark the bug as resolved with this workaround itself as the actual fix which involves changing the APIs is ruled out as per comment 17.

Comment 21 Martin Oberhuber 2014-08-27 18:21:54 EDT

Thanks all for collaborating to fixing this long-standing issue which is even mentioned in the Eclipse README (Hint Aron: You might consider updating the README now).

I have only one more question ... when our customer tested the workaround, they said that the 30-second hang still occurred often enough to be annoying ... not blocking any more but annoying.

So I was wondering if anybody knows where in GTK the 30-second delay for the event loop timeout is coded, and if / how it might be possible reducing that delay to eg 10 seconds, at least for some experiments ?

Comment 22 Arun Thondapu 2014-09-04 13:59:40 EDT

Verified in 4.4.1 RC2 and RC3