How to I remove non-current Eclipse C++ launch configuration?
What I expect is, the RUN directly related to myproject.exe, not pointing to otherproject.exe sometimes. this is misleading and bring up error. So why not let the closed project with its launching configuration, i.e. closedproject.exe be invisible. And It should be automatically visible if I am editing that C++ code?
Yes I did check the menu setting (De-/Selected both tried):
Windows->Preference->Run/Debug->Launching->Launch Configurations:
Filter configuration in closed projects
Filter configuration inc deleted or missing projects
But the closedproject.exe still in the drop down list or sometime even link to current project build.
What did I wrong or what is the correct/clear setting for this? Or maybe pls. help me to understand why multiple project.exe are listed there?
Or it is a Eclipse improve point?
Thanks to #howlger I have found more insights on the toolbar settings of Eclipse.
In general, Eclipse default toolbar lineup are overdone for beginners like me. It should be more concise and turn-up only needed thus more intuitive.
The "Launch Bar" makes it explicit and standing out. But those build/debug functions/buttons are already in basic toolbar set, thus would be redundant or even misleading if people click on the drop-down menu of "Launch configuration", which is also not clean & clear in principal.
For that reason, the Launch Bar could be disable (for beginners):
Preference=>Launching=>Launch bar | right panel=> uncheck
Enable the Launch Bar
The red-squared button of terminate could be useful while debugging and re-build, because the previous malfunctioning RUN & program could still resident in task manager thus prevent further build and turn-up permission error, There helps this "Terminate" button instead of restart Eclipse. BUT as said, this button also in basic toolbar set. But it is often shadowed by the out-standing Launching Bar :-).
It is also possible to fully customize the toolbar (and lock it):
Windows=>Perspective=>Customize Perceptive
Then choose the tool bar items to display.
For the issue of multiple historical "launching configurations", I will report to Eclipse.
I spend a lot of time going back and forth between SBT and IntelliJ, getting a file, line number, and error from SBT and navigating to it in IntelliJ. Is there a way to automate this at all? Even if it's only via IntelliJ's compiler, I'd love to be able to navigate to the next error project-wide.
To navigate between errors or warnings in IntelliJ you can do one of the following:
Use keyboard shortcuts F2 (Next) and Shift+F2 (Previous) respectively.
On the main menu, choose Navigate | Next / Previous Highlighted Error.
I am using Ctrl+Alt+Up/Down to scroll through the list of errors. This is inside the Compile Messages window. The SBT Console uses the same shortcut, as stated in the SBT wiki.
For this specific question, just use F2 (Next) and Shift+F2 (Previous);
But for any other questions related to shortcuts of IDEA, searching in the Settings-Keymap is better than in Google.
To go to next compilation error in the next file:
Command-0 (go to messages tab where compile errors are)
Down arrow until get to next error
Enter
Esc to get to back to code where this error is
The highly voted answer has not really answered the question. The provided solution of F2 only navigates through the errors in the current file. But picking up from the comments, the suggestion below is not the ultimate answer but is a little bit closer.
Select Problems as shown in the image below
This will list all files that have errors.
Use F2 to navigate through the errors.
At least with this method, it has narrowed down the files with the errors and are just a click away.
2022 UPDATE
This is a whole project, error to error, one-click solution after a 2-second setup. For both setups, optionally disable generate warnings for your compiler.
Windows/Linux Setup
Alt6 or click Project Errors tab of Problems tool window
CtrlNumPad+ or click
to expand all errors
MacOS Setup
Cmd6 or click Project Errors tab of Problems tool window
Cmd+ or click to expand all errors
Now click the first error in the Project Errors tab, fix it, then click the next error. Works regardless of build tool and may work in older versions of intellij than 2022.1.
Edit: Credit #Manuel Romeiro - the answer in his comment worked for a while, but stopped when intellij got confused somehow. Will update my answer if I figure that out.
Thanks #meridsa for providing setup step 1 for Mac. Also to #K. Symbol for syntax for showing keys in an answer (very cool).
For the mac I couldn't find anything that worked until I discovered the following
cmd + 1 -> f2 (on files) -> escape -> f2 (inside file) -> cmd + 1 -> repeat
For going to the next error across the entire project, use Alt+F2 instead of just F2.
On Mac, you can enable Fn regular key functionality in System Preference.
Choose Apple Menu > System Preferences.
Click Keyboard & Mouse.
Click the Keyboard tab.
Select the option Use All F1, F2, Etc. Keys As Standard Function Keys.
Quit System Preferences.
Eclipse 3.5.2 is not stopping in breakpoints. It's as if the debugger is using an older version of the source file.
Tried the usual refresh, clean all projects, build all, with no change.
Already in debug mode and the break point is checked.
*ok ended up deleting the whole project and checking it out again. but still curious what the issue was.
Perhaps you have pushed the Skip all Breakpoints button in the Breakpoints view.
Thanks guys, this really saved my day too.
I antecedently pressed on skip break points, if you did the same this will result on break point appearing with a backslash icon on them.
To bring it back to normal:
Switch to Debug perspective.
press on the breakpoints view tap -->> upper right hand corner of the screen, you also can go there by Window->show view-> breakpoints.
5th icon from the left you will see break point with backslash. press on that one.
To confirm, try putting break point on any line, and it should appear normally.
Press Ctrl + Alt + B
OR go through below steps
Clearing all Breakpoints fixed the issue
(within debugger perspective: Window -> Remove All Breakpoints).
Rebuilding the project did not work for me.
Sometimes you do start the debug mode but the debugger doesn't actually get attached/gets detached. I've also had this issue a few times when my laptop was reacting really slowly.
A reboot always solved it for me.
Also try doing a clean all (works miracles in Eclipse).
Please un check this from the Eclipse Menu.
Run->Skip all breakpoints.
I think this will be enabled permanently once You select the Remove all Break points option in the Debug/Breakpoints window.
Performing a "Clean All" worked for me.
Click on "Project" tab --> "Clean" menu-item.
In the "Clean" dialogue-box select "Clean all projects" radio-button. Leave the remaining values as default. Click "OK" button.
BINGO!!!The remote-debugging started working for me as beautiful as before.
It has also happened to me, in my case it was due to the GDB launcher, which I needed to turn to "Legacy Create Process Launcher". To do so,
either change the default launchers to the "Legacy Create Process Launcher", in Windows>Preferences>Run/Debug>Launching>Default Launchers.
or choose this launcher in the debug configuration of your application (Run>Debug configurations>choose your debug configuration). Under the "main" tab at the bottom, click on "Select other...", check the box "Use configuration specific settings" and choose "Legacy Create Process Launcher".
I had a conditional break point wrongly put on the method entry point. Removed that breakpoint and it worked.
Note: Tried Skip all Breakpoints, Clean all projects, Refresh, close Eclipse with no luck before nailing it.
In my case, somehow the breakpoints got automatically disabled because of this switch turned on, skip breakpoints.
Breakpoints have seemed to work and not-work on the versions of Eclipse I've used the last couple years. Currently I'm using Juno and just experienced breakpoints-not-working again. The solutions above, although good ones, didn't work in my case.
Here's what worked in my case:
deleted the project
check it back out from svn
import it into Eclipse again
run "mvn eclipse:eclipse"
Since the project is also a Groovy/Http-bulder/junit-test project, I had to:
convert the project from Java to Groovy
add /src/test/groovy to the Java Build Path (Source folders on build path)
include "**/*.groovy" on the Java Build Path for /src/test/groovy
I had all breakpoints enabled and configured as I should. But whenever I clicked "debug" it would only step through the program (press f5/f6) Turns out there was a rogue setting
Right Click project > debug configurations > "Debugger" tab > uncheck "Stop on startup at:" box
One reason for this situation can be, that you have pressed 'skip all breakpoints', when play- and another pictures are smaller than those normally are (because of higher resolution screen). Another thing can be, that break points are stopped only under VM threads, not under normal threads!
Go to (eclipse-workspace)\.metadata\.plugins\org.eclipse.wst.server.core and delete all tmp folders.
Clean and Restart server.
In my case I had to enable then disable an option in the Preferences.
I don't prefer the debug view to keep jumping when a breakpoint is hit so I disabled this option, but caused the issue in question.
The solution was to enable it again, start a debug session, the breakpoint is hit and shown in the UI, then disable again the option.
Looks like a bug in Eclipse 4.17
UPDATE
There is also another simpler way that will make Eclipse show the debugging highlight at the breakpoint or rather refresh the debugging UI to work as it should. After the breakpoint is reached, Eclipse will ask you to switch to debugging mode if you are not already in, click switch button, then activate the debug tab/view, you will notice that the stepping buttons are activated and the breakpoint line is highlighted.
First remove all 'toggle breakpoints' from the class file.
Then Eclipse requires a restart.
Then make sure 'Skip All breakpoints' is NOT enabled. If it is, make it disabled.
Then, add toggle breakpoint to the lines in your file and run on Debug mode.
A pop-up window must appear to confirm if you really want to Switch to debug mode. Say Yes and proceed.
I suddenly experienced the skipping of breakpoints as well in Eclipse Juno CDT. For me the issue was that I had set optimization levels up. Once I set it back to none it was working fine. To set optimization levels go to Project Properties -> C/C++ Build -> Settings -> Tool Settings pan depending on which compiler you are using go to -> Optimization and set Optimization Level to: None (-O0).
Hope this helps! Best
I had the same problem, and I found the real cause.
I had written some concurrent / multi-threads code, while I added some breakpoints inside the code running in a new thread. So, when JUnit tests ran over, and stopped soon, the code will not reach and stop at the breakpoints.
For this situation, we have to click and select "Keep JUnit running after a test run when debugging" check box at "Debug Configurations..."
switching workspace worked for me.
Go to File > Switch Workspace and choose different folder (workspace)
That's it and BINGO! Debugging started working for me as beautiful as before.
go breatpoint and click on 5th to eclipse->window>->show view->other->debug->breakpoint and click on 5th option (Skip All Breakpoints)
Make sure, that you are using the correct JRE version to debug your project. Especially if it's a third party project.
Also make sure, that there is no trigger point set for any breakpoint.
I had the same problem when I was using Eclipse Juno.. I installed Eclipse Indigo and it works fine. Try to reinstall eclipse.
A different solution worked for me. I also faced the same problem - debug points were not being updated, though they are shown correctly in the IDE editor and in Break Points tab.
My problem and solution are: While creating the project, the 'Default Output Folder' points to different location. At a later stage, I have mavenized the project, selecting "Project Right Click - Configure - Convert to Maven Project". So there are two sets of output folders exist in my project file system. Cleaning the project multiple times did not solve my problem. In the background it was pointing to different binary files. Finally, when I removed the Maven Feature and cleaned the project, this time everything worked fine. Env: Eclipse Juno and JRE is J2SDK 1.5.
I get all breakpoints skipped and marked as warnings when using -O2 in the compiler flags. Switched to -O0 -g in my makefile and breakpoints now work. Hope this helps.
If it doesn't stop even after unchecking SKIP ALL BREAKPOINTS, you can add this android.os.debug.waitfordebugger just before your breakpoint.
If you do this,your app will definitely wait for debugger at that point everytime,even if you are just running your app,which it will only find when your device is connected to eclipse.
After debugging you must remove this line for app to run properly or else android will just keep waiting for the debugger.
Try to restart eclipse, that works sometimes. I guess there is some kind of cache there.
In my case the debugged code in JBoss was older than the code in the Eclipse project. Rebuilding the .war solved the problem.
Facing same problem with Eclipse Luna.
Project clean didn't work.
Rebuild didn't work.
What makes it work is uninstall the app on the device before each debugging.
I use the Eclipse FileSync plugin for live remote debugging. Make sure you tick Allow different target folders & edit the Target folder file setting in the tree view.
Setting the Default target folder by the Browse... button without Allow different target folders will set all folders to the same target (I had both libs & classes set to the default for libs so my breakpoints did not update).
Since Eclipse 4.7/Oxygen released in June 2017, there is a new concept of "Triggers for breakpoints", which is displayed as a small "T" next to the breakpoint "blue bullet" icon.
All the other breakpoints that are initially suppressed by triggers
will be hit only after any of the trigger points has been hit. All the
triggers are disabled after a trigger point is hit and will be
re-enabled after the run.
In order to reset all the "trigger" flags, you need to do the following steps :
Switch to Debug perspective.
Right-click in the "Breakpoints" view
Select "Remove All Triggers".
Note : this step does not delete all your breakpoints, which occurs when selecting "Remove All" in the same contextual menu.
Note : the keyboard shortcut to enable the triggers is "Alt-R", which takes precedence on the shortcut to open the "Run" menu with its mnemonics, when the "Breakpoints" view is selected.
Is there any tutorial for debugging applications/ running profiler in eclipse? Please let me know thanks..
This will depend on what language you are using. How you setup for debugging PHP vs C++ is a little different as they use different underlying tools (PHP - Xdebug vs C++ - gdb)
In a general sense, you will configure the app much like you would set it up to run within Eclipse. In some cases you will have to be sure to enable debugging information within the code base for the debuggers to provide detailed information. From there you're looking at setting breakpoints, stepping, and setting up watches which is very similar language-to-language within the Debug Perspective in Eclipse.
A common scenario is to set a breakpoint within the codebase by clicking on the left bar in the editor, and selecting toggle breakpoint. Then click the debug button in the IDE and it should open the Debug Perspective and either break at the beginning of main, or will run to the breakpoint you set in the code. Once the break is hit, you will be able to browse the stack frames within one of the views within the perspective and you will see tabs for watches, breakpoints, etc. The buttons near the top that look similar to play, and then arrows jumping over dots are the way you control the execution from your breakpoint. If you click "step over" the code will go line by line in the source file you're in until it must goto another file to follow the execution of your code. It will not go into a function call, rather call it execute it and return to the next line in the current source. If you want to go into the function call and continue debugging from there, you would use the "step into" button which is right next to "step over" in most cases. Resume restarts regular execution and will run your program normally until the end or another breakpoint is hit.
Start from there and get comfortable with it and then start playing with things like conditional breakpoints and watches. Conditional breaks are exactly like breakpoints but they only stop execution if the condition you specify is met. With C++ this is usually done by right clicking on the breakpoint and providing the conditional expression where appropriate in the menu. (I forget the exact verbage)
Watches allow you to watch memory and have the program break when memory is read, written to, or both so you can inspect your application.
Some debuggers in Eclipse may lack some of these features or offer more advanced features than those listed above, but these concepts should get you well on your way.
Good luck!
I have what appears to be a very annoying problem. When compiling a project in Eclipse, I see no Console that shows the invocation of the Java compiler and the build results (as in NetBeans).
If I, for instance, import an existing project into Eclipse and invoke Project->Build Project, is there a view that will show me results of the compilation? While I know that my project contains a number of files that have errors, invoking Build Project shows no visual result/progress of the compilation. It does not show the list of errors so that I can quickly jump to them.
I'm aware that there is a "Problems" view, which shows a list of problems (and not just compiler errors) in all projects and not the particular project that I am working with, which makes it very inconvenient to locate and jump to source of the problem.
You can configure the problem view to show only problems in the current project:
Click on the small triangle at the far right of the view.
In the popup menu, select "Configure Contents..."
Select each item in the "Configurations" list and click on "Scope: On any element in the same project"
If you want to see the compiler working, you need open the "Progress" view.
Since Eclipse JDT provides its own built-in Java compiler, you generally do not see the invocation of Java Compiler.
The built-in Java compiler is tightly integrated with Eclipse and JDT, and provides the source indexing that enables powerful IDE features such as refactoring and quick fix.
Plus, it enables incremental build in background after each file modification, hence no visible "java" invocation.
You can replace/complete the java compiler with a javac` call of your own:
For instance, Using Alcatel-Lucent nmake with Eclipse JDT does precisely that, and uses a configuration launcher (which you can instruct to show a console):
You will need to add that special builder in the "builder" section of your project.
Do not forget you can create many "Problem view", and set one of them to show only problems for your current project.
Select: "on any element in same project"
Goto Windows->Show View->Console
or
Alt+Shift+Q,C
Console appears in tab with Problem view
Your question contains a couple of assumptions that you might want to re-think.
It does not show the list of errors so that I can quickly jump to them.
Errors are flagged in the edit window while you are editing. You can fix them on the spot, without having to "jump" anywhere.
If you drop an entire source file into your project, you may not be in an edit window on that file. (And, of course, that's not standard Eclipse usage.) The simplest way I know do deal with that is simply to "Refresh" the project and look in the Package Explorer view to see whether there are any errors detected (which will happen immediately if you "refresh" a file into a source folder). Double-click on any files which show an error icon and look at the right-hand side of the edit window to see exactly where the errors are.
I'm aware that there is a "Problems" view, which shows a list of problems (and not just compiler errors) in all projects and not the particular project that I am working with...
Unless you are using multiple projects, with inter-project dependencies, I find it useful to close all but the current project on which I'm working. Then the "Problems" view is specific to the current context.
Finally, I'd recommend looking at the Mylin "getting started" page for other hints on how Eclipse can help you focus on the current task.