Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 562608

Summary: Complete freeze of the UI while RCP debugging
Product: [Eclipse Project] Platform Reporter: Peter N <nosf3rat>
Component: DebugAssignee: Sarika Sinha <sarika.sinha>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: Lars.Vogel, loskutov, sarika.sinha
Version: 4.12   
Target Milestone: 4.16 M3   
Hardware: PC   
OS: Windows 10   
See Also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=33028
https://git.eclipse.org/r/161819
https://git.eclipse.org/r/162639
https://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=b4ba1469e0c91464256645c6a256a35ce291c841
Whiteboard:
Attachments:
Description Flags
Thread Dump none

Description Peter N CLA 2020-04-29 08:30:54 EDT 
Created attachment 282618 [details]
Thread Dump

We have an RCP product based on Eclipse
Our product has debug implmentation extensions based on the Eclipse Platform Debug Framework

Sometimes there is a UI freeze (deadlock?) during the debug process when there is a lot of Expression View items (epxpressions)
I didn't found actual deadlock cause in the Java thread dump. And freeed main thread does only contain Eclipse/Debug stack frames and does not contain my RCP stack frames
And freeze didn't end in 15 mins, so user just terminates our RCP

The main (UI) thread is freezed on "ExpressionView.canPaste" execution

I found that there were already 3 bugs registered with similar freeze stack (also on "ExpressionView.canPaste" call)
But there was no fixes on them:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=303738
https://bugs.eclipse.org/bugs/show_bug.cgi?id=372280
https://bugs.eclipse.org/bugs/show_bug.cgi?id=409560

Freeze thread dump is attached
Comment 1 Sarika Sinha CLA 2020-04-29 09:14:18 EDT 
Do you face this only with Windows 10? Can you try it with other OS or Windows 8?

Windows Defender could have played a role Bug 548443. You can try disabling it as well.

As I see other Console read/write also being blocked in the attachment.
Comment 2 Andrey Loskutov CLA 2020-04-29 10:05:00 EDT 
Just a naive question: why do we need that "canPaste" check at all:

org.eclipse.debug.internal.ui.views.expression.ExpressionView.getClipboardText(ExpressionView.java:234)
	at org.eclipse.debug.internal.ui.views.expression.ExpressionView.canPaste(ExpressionView.java:193)
	at org.eclipse.debug.internal.ui.actions.expressions.PasteWatchExpressionsAction.isEnabled(PasteWatchExpressionsAction.java:43)
	at org.eclipse.ui.actions.RetargetAction.setActionHandler(RetargetAction.java:268)
	at org.eclipse.ui.actions.RetargetAction.partActivated(RetargetAction.java:146)

Then independently on the clipboard state, the clipboard is empty, paste action will not explode - it will just don't do anything. So what is the point in checking the clipboard on any view activation? Even if it is always enabled, nobody will ever notice that, but knowing that permanent clipboard checks may slow down UI, we should simply remove this code.
Comment 3 Sarika Sinha CLA 2020-04-30 05:34:32 EDT 
(In reply to Andrey Loskutov from comment #2)
> Just a naive question: why do we need that "canPaste" check at all:
> 
> org.eclipse.debug.internal.ui.views.expression.ExpressionView.
> getClipboardText(ExpressionView.java:234)
> 	at
> org.eclipse.debug.internal.ui.views.expression.ExpressionView.
> canPaste(ExpressionView.java:193)
> 	at
> org.eclipse.debug.internal.ui.actions.expressions.
> PasteWatchExpressionsAction.isEnabled(PasteWatchExpressionsAction.java:43)
> 	at
> org.eclipse.ui.actions.RetargetAction.setActionHandler(RetargetAction.java:
> 268)
> 	at
> org.eclipse.ui.actions.RetargetAction.partActivated(RetargetAction.java:146)
> 
> Then independently on the clipboard state, the clipboard is empty, paste
> action will not explode - it will just don't do anything. So what is the
> point in checking the clipboard on any view activation? Even if it is always
> enabled, nobody will ever notice that, but knowing that permanent clipboard
> checks may slow down UI, we should simply remove this code.

I was investigating the same yesterday, I see 2 options:
1. Disable the ClibboardText check and keep the Paste enabled all the time
2. Can we differentiate between the view initialization check and the others to call this selctively.
Comment 4 Andrey Loskutov CLA 2020-04-30 05:40:21 EDT 
(In reply to Sarika Sinha from comment #3)
> 
> I was investigating the same yesterday, I see 2 options:
> 1. Disable the ClibboardText check and keep the Paste enabled all the time
> 2. Can we differentiate between the view initialization check and the others
> to call this selctively.

I would disable that check completely and say "paste" is enabled all the time, it is really not worth the extra code/effort IMHO.
Comment 5 Sarika Sinha CLA 2020-04-30 08:05:11 EDT 
I see a similar Bug 33028, similar fix should work.
Comment 6 Eclipse Genie CLA 2020-04-30 08:11:02 EDT 
New Gerrit change created: https://git.eclipse.org/r/161819
Comment 7 Sarika Sinha CLA 2020-05-06 01:04:08 EDT 
(In reply to Eclipse Genie from comment #6)
> New Gerrit change created: https://git.eclipse.org/r/161819

Will not work as Clipboard code already makes sure that it is in UI Thread.
Comment 8 Sarika Sinha CLA 2020-05-07 06:58:20 EDT 
(In reply to Sarika Sinha from comment #3)
> 
> I was investigating the same yesterday, I see 2 options:
> 1. Disable the ClibboardText check and keep the Paste enabled all the time
> 2. Can we differentiate between the view initialization check and the others
> to call this selctively.

I was surprised by the finding that even if Clipboard does not have any data or getClipboardText() method return null, the Paste is always enabled.

So I am going ahead with always returning true for canPaste()
Comment 9 Eclipse Genie CLA 2020-05-07 07:02:14 EDT 
New Gerrit change created: https://git.eclipse.org/r/162639