Community
Participate
Working Groups
Build: I20030205 The step functions are disabled when debugging in this build. The shortcut keys (F5-F8) don't work, and the actions are greyed out in the menu. The toolbar buttons still work however.
I just did a quick test in the latest build - the step keys work for me (and the actions are enabled in the Run menu).
Is the debug view visible? See bug 30463.
I just tried with a fresh workspace and they work. However, in my existing workspace carried over from previous builds they do not work. This is both with a runtime workspace, and with running a simple java application. This is in the standard debug perspective, with the debug view open and active. I suspect this is linked to the other bug I just entered (30982), that the variables view also doesn't work. Everything else looks normal. Breakpoints work, the display view works, but the variables view is empty and the keys for stepping don't work. There are no errors in the log. Anything else I can try to help track this down?
Hmmm. I'm using the same workspace that I've had for months.
*** Bug 30982 has been marked as a duplicate of this bug. ***
one thing to try is to re-set the perspective or close/re-open the views to see if this has an effect. It might be something to do with view initialization.
Closing/reopening views or resetting the perspective didn't fix it. I will sniff around a bit further myself.
After resetting the perspective, shutting down and restarting fixed the problem. I also noticed this in the log around the time when I reset the perspective: !ENTRY org.eclipse.ui 4 4 Feb 05, 2003 12:31:38.489 !MESSAGE Unable to find Action Set: org.eclipse.jdt.debug.ui.JDTLaunchActionSet
This is also a problem for me with build i0205 on linux-gtk. Note that I also have a customized debug perspective.
I haven't been able to reproduce it from scratch. I've tried going back to older versions such as M4 and 2.0.2, and then going forward again to I20030205, but no luck. It is still reproducible with my workspace, which I have placed on the anonymous FTP server. The file is in anon/out/30971.zip. Contact me directly if you need more instructions on accessing the file. It can be debugged by directing a runtime workbench launch configuration at it, but I was at a loss to figure out how to debug it. I wonder how many other people are seeing this, or if it's something specific about how we set up our workspaces?
*** Bug 31140 has been marked as a duplicate of this bug. ***
I also saw the problem: shortcut keys were disabled and the Variables view would not show any variable. I worked around the problem by closing the Debug view and reopening it. From there on, shortcut keys were enabled and the Variables view would show variables.
In this particular workspace, the debug actions in the run menu are not getting selection change events from the debug view. As well, the variables view is not receiving selection change evnets. It appears to be related to the workbench support for listening to selection changes from a specific part. The step actions in the toolbar work, as they are view actions, receiving selection change events from the view. However, the global step actions and variables view register via the following API. When I place a breakpoint in the associated callback method (#selectionChanged(IWorkbenchPart part, ISelection selection)), it is never hit. /** * @see IWorkbenchWindowActionDelegate#init(IWorkbenchWindow) */ public void init(IWorkbenchWindow window){ // listen to selection changes in the debug view setWindow(window); window.getSelectionService().addSelectionListener (IDebugUIConstants.ID_DEBUG_VIEW, this); }
adding as CC. Nick, has there been any recent changes in the part specific selection service?
The only recent change related to the selection service is that a couple more of our views (tasks, bookmarks) now set a selection provider, but that should not affect the part-specific selection service. Who is hooking the listener? Is it the debug actions themselves? Are you sure the debug actions are getting initialized properly? Perhaps there's a problem with the contributions themselves.
It's believed that this bug is related to (caused by) Bug 31356.
Fix released to the HEAD stream (Perspective, ViewFactory, WorkbenchPage).
*** Bug 31025 has been marked as a duplicate of this bug. ***
*** Bug 31356 has been marked as a duplicate of this bug. ***
*** Bug 31661 has been marked as a duplicate of this bug. ***
*** Bug 31658 has been marked as a duplicate of this bug. ***
*** Bug 31655 has been marked as a duplicate of this bug. ***
*** Bug 31607 has been marked as a duplicate of this bug. ***
*** Bug 32135 has been marked as a duplicate of this bug. ***
*** Bug 32462 has been marked as a duplicate of this bug. ***
*** Bug 32510 has been marked as a duplicate of this bug. ***
I am still having the problem described. I am running Win2000 SP2. Eclipse 2.1 RC2. Sun JDK 1.3.1_03. I have reset the Debug perspective, restarted, created a new workspace, imported old projects, created new projects. I've done pretty much everything I can think of to reset my environment. I can not get the Debug Actions (Step Into, Step Over, Step Return) to become enabled. What else can I do? The log file is empty.
Please use RC3a
No, the fix went in for RC1, so it should work in RC2. Reopening for investigation. Simon, can you please look at this today, since Eduardo is away today?
Charles, from your comments, it seem to indicate you can recreate this problem by using 2.1 RC2 and a new workspace?
Created attachment 4292 [details] Eclipse project that can recreate the error I created a brand new workspace and then created this project within it.
Yes, the problem occurs with RC2. After some more testing, it is the scarpbook pages that are the problem! I created a sample project that I used to test the theory. If you debug the class as is (set a breakpoint of the first line of main()) then you will have the step actions. However, if you execute the scrapbook page supplied, you will NOT have the actions.
Moving to the JDT debug team to investigate.
Removing milestone.
The problem with the scrapbook is different than the problem already fixed by this bug. I am going to mark this bug as fixed and open a new bug to track the new problem (bug 35525).
Verified.