Summary: | Sometimes the org.eclipse.ui.edit.text.goto.lineStart doesn't work (requires Eclipse restart to work again) | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Fabio Zadrozny <fabiofz> |
Component: | UI | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | major | ||
Priority: | P3 | CC: | rolf.theunissen |
Version: | 4.17 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows 10 | ||
Whiteboard: |
Description
Fabio Zadrozny
2020-08-04 08:15:41 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). 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? 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. (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 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. 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. 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). |