Community
Participate
Working Groups
I'm using Eclipse 4.2RC3. When in the debug perspective, the F5 - F8 keybindings often don't work. I often have to press the key twice to get it to work, and sometimes I have to click on the stack frame to get the key to work. Debugging on OS X is very painful.
I've seen this to on linux PW
Remy mentioned this at EclipseCon. I thought there was a fix. I'm sure there is another bug report, but I can't find it now.
I had this problem a while ago and I'm not 100% if it really got fixed by Bug 297899
I think this is due to a race condition due to lazy loading of the step command handlers with how the step action enablements are computed. The DebugCommandActionDelegates are first created as part of the @CanExecute check on the step-X handlers, and so their DebugCommandAction instances aren't current with the active debug context. The DebugCommandAction enablement state is requested using an UpdateJob, which is not joined, and so doesn't complete before the DebugCommandAction/DebugCommandActionDelegate initialization is finished. This causes the step action to be marked as disabled until the background update request is able to update the action delegate's enablement state. This background update doesn't occur in time before the step handler's @CanExecute returns. What's funny is that the DebugCommandService has already queried the step availabilities (after a breakpoint or exception), but it doesn't keep ahold of the current state. This problem could be circumvented if the DebugCommandService had a way to access the last state for a particular command. A few stack traces: Immediately on pushing F5 for the first time; the CommandLegacyActionWrapper is the action wrapper pushed in by ActionDelegateHandlerProxy. The action wrapper is disabled. Daemon Thread [Thread-1] (Suspended (entry into method setEnabled in CommandLegacyActionWrapper)) CommandLegacyActionWrapper.setEnabled(boolean) line: 456 StepIntoCommandAction(DebugCommandAction).setActionProxy(IAction) line: 109 StepIntoCommandActionDelegate(DebugCommandActionDelegate).init(IAction) line: 51 ActionDelegateHandlerProxy$2.run() line: 466 SafeRunner.run(ISafeRunnable) line: 42 ActionDelegateHandlerProxy.initDelegate() line: 485 ActionDelegateHandlerProxy.loadDelegate() line: 603 ActionDelegateHandlerProxy.updateDelegate(IAction, IEvaluationContext) line: 312 ActionDelegateHandlerProxy.setEnabled(Object) line: 522 E4HandlerProxy.canExecute(IEclipseContext, IEvaluationContext) line: 56 GeneratedMethodAccessor1.invoke(Object, Object[]) line: not available DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 Method.invoke(Object, Object...) line: 597 MethodRequestor.execute() line: 56 InjectorImpl.invokeUsingClass(Object, Class<?>, Class<Annotation>, Object, PrimaryObjectSupplier, PrimaryObjectSupplier, boolean) line: 229 InjectorImpl.invoke(Object, Class<Annotation>, Object, PrimaryObjectSupplier, PrimaryObjectSupplier) line: 210 ContextInjectionFactory.invoke(Object, Class<Annotation>, IEclipseContext, IEclipseContext, Object) line: 131 HandlerServiceImpl.executeHandler(ParameterizedCommand, IEclipseContext) line: 166 KeyBindingDispatcher.executeCommand(ParameterizedCommand, Event) line: 276 KeyBindingDispatcher.press(List<KeyStroke>, Event) line: 497 KeyBindingDispatcher.processKeyEvent(List<KeyStroke>, Event) line: 548 KeyBindingDispatcher.filterKeySequenceBindings(Event) line: 369 The action delegate initialization registers an UpdateJob to verify the step ability status: Daemon Thread [Thread-1] (Suspended (entry into method canExecute in AbstractDebugCommand)) StepOverCommand(AbstractDebugCommand).canExecute(IEnabledStateRequest) line: 253 DebugCommandService.updateCommand(Class, Object[], IEnabledTarget[]) line: 181 DebugCommandService.updateCommand(Class, IEnabledTarget) line: 134 StepOverCommandAction(DebugCommandAction).init(IWorkbenchWindow) line: 207 StepOverCommandActionDelegate(DebugCommandActionDelegate).init(IWorkbenchWindow) line: 59
This is a major productivity killer.
One thing I noticed with this is in 4.2 we are only calling canExecute(*) once, during the execute phase, but in 3.8 we called canExecute(*) twice (once earlier than the execute). Adding back that extra call seemed to make it harder to hit this condition, but it was still there sometimes. Michael, when debugging this in 3.8 there were a lot more calls to the canExecute/UpdateJob, usually triggered in asyncExecs(*) by debug model changes. Could you have a look at this tomorrow and see if there's something we did that is causing less debug model changes to be broadcast? PW
*** Bug 387057 has been marked as a duplicate of this bug. ***
*** Bug 389383 has been marked as a duplicate of this bug. ***
Not sure if this helps, but when a breakpoint is hit and I first click onto the call stack (if that´s what it´s called), I only need to press F5, etc. once. Using Eclipse 4.2.1 on Win XP SP3.
*** Bug 391583 has been marked as a duplicate of this bug. ***
Any progress on this bug? This is a huge productivity killer for OS X developers. Bug#372941 references this bug, but I'm not sure which one is the "true" bug. Any fix on the horizon?
no, not yet. PW
Looking on the debug side of things we have the DebugCommand* classes that get loaded at startup and enable correctly, but then when debugging starts, another set of delegates is created which end up disabling the handlers. After the first key press the handler re-evaluates its enabled state and correctly enables (again) then the following key presses work. I need to poke around a bit more to see if we broke something on the debug side or not.
Created attachment 222852 [details] Covert launch view actions to command contributions Hi Mike, This patch gets rid of the problematic actions from the launch view and contributes them through the org.eclipse.ui.menus extension. The problem with this solution is that we have an action that lets the user show/hide the run control actions in the view toolbar. We have a system property to test for, but I don't know of a way to force the toolbar to re-evaluate its contributions. Instead, I put in a crude update that directly turns off/on the toolbar contributions.
I like the fix, and it makes debugging on the Mac usable again. I do agree though that we would need a different solution to show/hide the toolbar, because the current solution will only show/hide the platform contributed actions - I would assume if someone contributed an action to the stepOverGroup (for example) that that action would also show/hide. Also this fix helps the work in progress from bug 390869 Paul, is it a supported scenario in Platform UI to have a contributed action (plugin.xml) and an action added via code that share a command id work when both are used at the same time? If not than this bug can be moved to platform debug, as the proposed fix is completely on the debug side.
Looks like my proposed fix is severely broken in 3.8 for a change. Besides the broken switching between debug view toolbar on/off, the commands are always enabled until they are first run.
Created attachment 223052 [details] Updated patch to convert debug action set to command contributions The reason that the commands don't work in 3.8 is that they seem to conflict with the actions defined in the main menu. This patch doubles down on the command contributions with the main menu and toolbar. It fixes the enablement issues in 3.8, but toggling debug view toolbar still doesn't work. Also a bad side-effect is that the Customize Perspective->Command Groups->Debug doesn't show the debug actions anymore.
I would be reluctant to change the action contributions to command contributions in a service release. Besides new bugs, this *might* also result in different ordering of the menu entries.
Created attachment 223367 [details] ActionDelegateHandlerProxy patch Seems like part of the fix to bug 361562 added an extra call to loadDelegate(), which when removed, the debug actions start working as expected again. I confirmed that removing the extra loadDelegate call does not affect the fixes for bug 371130, bug 371131 or bug 361562 - Pawel can you test to confirm it does not affect CDT? The easiest way I reproduced the multiple key press problem was: 1. start target workspace 2. debug Java application to breakpoint 3. hit one of F5-F8 after it suspends
Thanks Mike! I gave the patch a quick try with CDT and it fixes the keybinding problem. I also didn't see any issues with the CDT action delegates, though my test pass was not exhaustive.
(In reply to comment #19) > Created attachment 223367 [details] > ActionDelegateHandlerProxy patch I've had a look at this as well, and it removes the problem for me. Do you want to go ahead and put it in, and we'll get some more widespread testing in the M build? Thanx for looking into this, Mike. PW
(In reply to comment #21) > (In reply to comment #19) > > Created attachment 223367 [details] > > ActionDelegateHandlerProxy patch > > I've had a look at this as well, and it removes the problem for me. Do you > want to go ahead and put it in, and we'll get some more widespread testing > in the M build? > > Thanx for looking into this, Mike. > > PW Sure, if you wouldn't mind putting it in for me.
I did not test the fix, but looking at the change it *might* result in early and unwanted plug-in loading. Please test this before committing.
(In reply to comment #23) > I did not test the fix, but looking at the change it *might* result in early > and unwanted plug-in loading. Please test this before committing. I agree, we should be careful. This patch will remove the second part of the if, which can load the delegate after its plugin is already active, but earlier than it would have in regular 3.x startup. So it just removes the "load the delegate earlier than usual" call. Released as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_2_maintenance&id=9aefcba2ae27ba3d1b36baf26009806c0b6dd28d Thanx Mike, PW
I have this issue too but my behavior is different i dont know if i should open a new bug or not. When i go in the debug perspective. In any window the F6, F7 and F8 keys are working fine. F5 key NEVER work in source code. I always have to go in the debug stack for it to work. I removed the F5 hot key binding everywhere. Only step into have it now. But not working either. I try to make a custom perspective and play with the Command Groups and Toolbars see if its affecting anything but after 15 minutes i understood never to do that again. So yeah, that F5 key is a mistery.
(In reply to comment #25) > I have this issue too but my behavior is different i dont know if i should > open a new bug or not. > > When i go in the debug perspective. In any window the F6, F7 and F8 keys are > working fine. > > F5 key NEVER work in source code. I always have to go in the debug stack for > it to work. > > I removed the F5 hot key binding everywhere. Only step into have it now. But > not working either. > > I try to make a custom perspective and play with the Command Groups and > Toolbars see if its affecting anything but after 15 minutes i understood > never to do that again. > > So yeah, that F5 key is a mistery. Please try whether the latest 4.2.2 or 4.3 M4 build fixed the issue http://download.eclipse.org/eclipse/downloads/drops4/M20121212-1800/ http://download.eclipse.org/eclipse/downloads/drops4/I20121213-1200/
It is ok with 4.2.2 and 4.3 M4 But in my eclipse 4.2 SR1 is the JEE Birt version. With Android SDK and GWT plugin. Plus some utilities like findbugs, jboss tools, Git, subversive, etc. I dont know if it can affect the debug perspective.
