Bug 565805 - Sometimes the org.eclipse.ui.edit.text.goto.lineStart doesn't work (requires Eclipse restart to work again)
Summary: Sometimes the org.eclipse.ui.edit.text.goto.lineStart doesn't work (requires ...
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.17   Edit
Hardware: PC Windows 10
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: Platform-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-04 08:15 EDT by Fabio Zadrozny CLA
Modified: 2022-03-08 09:45 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fabio Zadrozny CLA 2020-08-04 08:15:41 EDT
I still don't know exactly why this happens, but it does seem to happen sporadically to me (and then, it appears like the only solution is restarting Eclipse to get it to work again -- I saw this in the "org.eclipse.ui.edit.text.goto.lineStart" command (but that may be because it's one of the most common actions used -- other commands such as "select to the line start" instead of just "go to the line start" were still working even when that command wasn't).

I've attached a debugger to a running session where this was happening, so, I'll describe what I see below.

- org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(List<KeyStroke>, Event) is called with the parameters: ([HOME,], event).

- Everything seems to be normal and it ends up calling: org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(ParameterizedCommand, Event) with: 

```
Command ParameterizedCommand(Command(org.eclipse.ui.edit.text.goto.lineStart,Line Start,
		Go to the start of the line of text,
		Category(org.eclipse.ui.category.textEditor,Text Editing,Text Editing Commands,true),
		,
		,,true),null), defined: true, handled: true in 
	context chain: WorkbenchContext -> TrimmedWindowImpl (IDEWindow) Context -> PerspectiveImpl (org.python.pydev.ui.PythonPerspective) Context -> PartImpl (org.eclipse.e4.ui.compatibility.editor)  removeOnHide org.python.pydev.editor.PythonEditor (codegen_package) Context
```

- handlerService.executeHandler(parameterizedCommand, staticContext); is executed (inside the executeCommand).

- It enters at org.eclipse.core.commands.Command.executeWithChecks(ExecutionEvent) and when it's called it doesn't work because `org.eclipse.core.commands.Command.handler == null` (so, it throws a `new NotHandledException("There is no handler to execute for command org.eclipse.ui.edit.text.goto.lineStart")`.

So, it seems like the reason is that there's no handler for it, but what I don't know is why there's no handler for "org.eclipse.ui.edit.text.goto.lineStart" in that case (the context appears correct for me and even closing all the editors doesn't make it work -- i.e.: closing all editors and opening just a plain text editor doesn't activate that action later on (so, only an Eclipse restart makes it work again).

-- so, the difference is that on the regular use case (before it fails), I can see that `org.eclipse.ui.internal.WorkbenchHandlerServiceHandler@2aabd5a0` is set as the handler (org.eclipse.core.commands.Command.handler) and when it fails that field is set to null (and it doesn't recover from that until an Eclipse restart).

Still, I don't know why the handler would become null in the first place...
Comment 1 Fabio Zadrozny CLA 2020-08-04 08:44:39 EDT
On another note, after debugging a bit more, it seems that it's normal for the handler to become null in:

org.eclipse.ui.texteditor.KeyBindingSupportForAssistant.assistSessionStarted(ContentAssistEvent)

and then it should become activated again in:

org.eclipse.ui.texteditor.KeyBindingSupportForAssistant.assistSessionEnded(ContentAssistEvent)

but I guess that under some racing condition sometimes this doesn't work as intended (or the assistSessionEnded isn't called as it should) or some other place (which I don't know of) does something similar and they don't talk appropriately (as a note, this is hard to reproduce reliably -- I see it happening something like once every couple days).

Doing that is definitely not thread safe (but I don't know if there are threads doing anything related to changing the command handler).
Comment 2 Rolf Theunissen CLA 2020-08-05 02:37:29 EDT
By looking at the code, ReplacedCommand#activate() might be suffering from a race condition.
The workaround for Bug 297834 might cause that the handler is not activated again. Would you be able to add a conditional breakpoint at this line, to validate that indeed here the problem arises?
Comment 3 Fabio Zadrozny CLA 2020-08-05 07:31:53 EDT
I can add a conditional breakpoint (what would that be?). Note that it needs to be something that doesn't always happen, only something which would trigger the error or after the error is already there (because the error is hard to reproduce and happens only seldomly having to stop on regular situations is unwieldy).

As a note, I stumbled once more in this yesterday and one thing I can confirm is that all of the actions overridden in the content assist are lost, not just HOME (so, things as `Ctrl+Up / Ctrl+Down` also don't work anymore), which really seems to indicate an issue with org.eclipse.ui.texteditor.KeyBindingSupportForAssistant.
Comment 4 Rolf Theunissen CLA 2020-08-05 08:49:13 EDT
(In reply to Fabio Zadrozny from comment #3)
> I can add a conditional breakpoint (what would that be?). Note that it needs
> to be something that doesn't always happen, only something which would
> trigger the error or after the error is already there (because the error is
> hard to reproduce and happens only seldomly having to stop on regular
> situations is unwieldy).

For such situations conditional breakpoints [1] are useful. They trigger only when a certain condition is not true, in this case, the condition when the handler restore would be skipped. So you can use as regular, until the condition becomes true.

[1] https://wiki.eclipse.org/FAQ_How_do_I_set_a_conditional_breakpoint%3F
Comment 5 Fabio Zadrozny CLA 2020-08-05 16:52:38 EDT
Oh, I know how conditional breakpoints work, what I can't find out is a good condition on when this happens (I can detect it after it happens, but then it's too late, I'm already in that condition)... 

I'm actually experimenting printing things through breakpoints to see if the tracing indicates something, but if things happen slower due to prints/debug I may not be able to reproduce it.
Comment 6 Rolf Theunissen CLA 2020-08-06 02:04:12 EDT
I would put a conditional breakpoint in KeyBindingSupportForAssistant at line 73, with contents handler.getClass().isInstance(command.getHandler()), to simulate an else statement. Or when you are changing the code, add a real else statement, and add a breakpoint in the else block. This should have least impact on timing.
Comment 7 Fabio Zadrozny CLA 2022-03-08 09:45:55 EST
As a note, I still have this issue, but so far I haven't been able to reproduce it when the debugger is connected (it seems that if I start it with a breakpoint in place changes in timing make it so that it doesn't happen anymore -- I can only manage to attach a debugger afterwards).