I'm trying to debug an executable which has been created with CMake configuration
SET(CMAKE_BUILD_TYPE Debug)
However, CLion does not hit any breakpoints. What could be the problem?
I had the same issue today. I figured out that the configuration for the project was not set to Debug. After setting the configuration to Debug all the breakpoints are hit.
Please ensure that you have following configuration:
Select the MenuItem Run/EditConfigurations
Select the right Target
Select Debug as Configuration
Now the breakpoints should be hit.
In case this helps someone else, it turned out that my (somewhat embarrassing) issue was that I was hitting Run instead of Debug. So in the Run menu don't use the play icon, instead choose the cute bug icon instead. Choosing Run was causing it to automatically build the non-debug build so breakpoints wouldn't work. Once I started choosing the bug icon, the breakpoints worked like a charm.
As it has turned out, the executable was compiled with following CMake options (further down in the script):
SET(CMAKE_C_FLAGS_DEBUG "-D_DEBUG")
This was breaking debug functionality for CLion (it was also breaking most of the debug functionality of gdb)
I also had the same Problem. Since 2016.3 CLion changed the CMake workflow so that only one configuration is allowed at one time clion new workflow
The solution is File -> Settings -> Build, Excution, Deployment -> change the build configuration
In my case my CMake option CMAKE_BUILD_TYPE was already set to DEBUG on CMake Settings. However, it was the command set(CMAKE_BUILD_TYPE Release) in the CMakeLists.txt, which was merged by git pull and overrode the CMake Settings while execution. I could not figure out earlier as CMake Debug console was showing -DCMAKE_BUILD_TYPE=Debug
When I changed it to set(CMAKE_BUILD_TYPE Debug) breakpoints were hit again.
In case this helps someone else:
In my case I had to set the -DCMAKE_BUILD_TYPE option to Debug explicitly in Settings -> Build, Execution, Deployment -> CMake
I had a different issue that caused my breakpoints not to be hit. I develop both embedded apps and native MacOS console apps with CLion. For the embedded work, GDB needs to be set for your selected Preferences/Toolchains.
For debugging console apps LLDB needs to be selected in Preferences/Toolchains. If it is left on GDB, my breakpoints don't work. Set to LLDB here:
I had a comma in my project path. Removing the comma fixed the problem for me.
In 2019.3, it turns out to be CLion/Preference/Build,Execution,Deployment/CMake/Build type/Debug.
My problem was with the -ffile-prefix-map flag. Once I removed it, everything worked fine.
See https://youtrack.jetbrains.com/issue/CPP-23159 and https://youtrack.jetbrains.com/issue/CPP-15850
I had the same issue. I noticed that every time I click the debug option, the "Antimalware Service Executable" process starts. I created an exclusion for MinGW folder in windows Defender and it worked fine...
Just like minecrawler said in github, if your os is linux, your should set：
file/Settings/Build,Execution,Deployment/Tllochains/Debugger from Bundled GEB or gdb to Bundled LLDB.
I tried and it worded！
In my case (Linux / Ubuntu) the problem was somehow related to mounted directory.
The project was initially opened in CLion from /media/username/ssd/repo/git/projectname. The breakpoints were always disabled with message No executable code is associated with this line.
Then I opened the same project from a symlinked directory
~/git -> /media/username/ssd/repo/git and the breakpoints began to work fine.
In my case I had to edit the file so that everything was compiled again instead of using cache.
In my case, the problem is forget to comment out optimize option add_definitions(-O3) in cmakelists. which let compiler go release.
in the case of "the platform is currently not connected" of CLION for RUST, it turns out there is an authorization step which is not enabled on CLION 2022.2 version.
download the correct version solves the problem
Related
I'm using CLion 2022.2 (fresh install, Windows 11) and the newest version of the Rust plugin.
When I'm trying to run a project, everything works just fine. But when it comes to debugging, it appears that I can't use breakpoints at all. I can place them, but while debugging, all of them are non-active.
When I hover over them, a message pops up that says: "The breakpoint will not currently be hit. No executable code is associated with this line.". However, it is clear that executable code is present. Example:
The configuration settings is following:
...and the toolchains settings are here:
I've seen a couple of possible solutions, but none of them worked for me. But I believe that the Rust community will help me. Any advice would be appreciated!
I've just installed JetBrains WebStorm 2016.1.1 Build #WS-145.597 for evaluation on OS X latest.
I want to use TypeScript but there is an immediate problem: I have enabled the TypeScript compiler in settings but in the Typescript Compiler tool window is complaining that it "Cannot start compiler process".
I've noticed that the build date on the WebStorm About box was yesterday (March 30 2016) so this may be a recently introduced issue.
Is anyone else having this problem? Anyone got an idea how to sort it?
Setting the TypeScript compiler alone didn't solve this for IntelliJ IDEA 2016.2.1 on Linux. I had to go back through my older project that didn't have the problem to find the solution.
After setting up your typescript compiler below.
I then had to directly edit this same setting within my project's .idea directory. Within your project structure, navigate to your .idea directory then locate and open file typescript-compiler.xml like below.
Now add the following xml option element after the "useConfig" option element:
<option name="nodeInterpreterTextField" value="$PROJECT_DIR$/../../node/bin/node" />
Be sure to change the directory path to your instance of node.
Sadly, this solution we be overridden every time you edit and save your settings. IDEA will have to fix their bug for a lasting solution.
I think you need to specify a node interpreter in the typescript settings:
I just started using Xcode to program a C++ openCV project.
The project is set up with an external makefile, /usr/bin/gnumake as build tool, and the program compiles and runs fine.
However, breakpoints gets skipped no matter what i do.
I have tried making a new project, selecting between gdb and LLDB, restarting Xcode++
There are numerous threads about this issue, but most talk about "Load Symbols Lazily", but as far as I know, this is not an issue in Xcode 4.5.2.
It is probably my limited Xcode knowledge that causes the error.
Help is greatly appreciated.
I could resolve my similar problem by disabling "Link-Time Optimization" for the Debug build settings.
Make sure that any kind of code optimization is disabled in your debug build settings (code stripping, optimization, etc). Then check that you really run the debug build and not the release version.
It would be great if XCode could automatically warn you when you have build settings that possible break the debugger...
I have a project for Mac OS X 10.5 that I'm building on 10.6 using Xcode 3.2. When I use GCC 4.2 for Debug build and hit a breakpoint, Xcode debugger displays local variable information normally. If I choose LLVM GCC 4.2 or Clang LLVM, when I hit breakpoint, local symbols are not available, and GDB says No symbol 'self' in current context if I try to print self or any other local symbol. In all cases Generate debug info option is set. The Debug configuration is set to $(NATIVE_ARCH) and 10.5 SDK, Build active architecture only option is set. When GDB starts, I can see it is being configured as x86_64-apple-darwin. I must be missing something obvious. How do I make GDB show local symbols when using a LLVM compiler?
For those not familiar, a little more detail to cdespinosa's answer, which worked for me, and which I voted up.
From the Xcode menu, select Project > Edit Project Settings...
Choose the Build tab
In the search box type "Optimization Level", choose that field, and select None.
Next search for "Debug Information Format", choose that field, and select "DWARF" or "DWARF with dSYM".
Would have put this in comments to his post if I had the privs. ;)
This cost me some serious time, and was frankly kind of sloppy on Apple's part, but in general I can't complain.
Make sure you're building with Dwarf symbols and no optimization. llvm is a new back-end, and not all of its optimized codegen is hooked up to debug symbol generation yet.
This may help. Try turning off "Link-Time Optimization" in the project's build options. That fixed a problem I had with missing debug symbols.
In fact, that fixed a bunch of weird problems I was having with Clang. I'd say that feature is just too bleeding edge to use yet.
GDB from FSF only added support for JIT code very recently.
I don't know whether Apple-supplied GDB has support for it at all (do you get reasonable stack traces?). If it does, this support is (apparently) incomplete.
I was having this problem and solved it by putting a tick next to the menu item: "Project > Set Active Build Configuration > Debug". Previously, the "Release" option was selected. Locals started showing up in the debugger for my project from then on.
My problem is that I set some breakpoints in my code and some of them aren't working. In some places it complains about "Unresolved Breakpoint".
Does anyone have any clue why this is happening? I am using gdb, by the way.
EDIT: Yes, of course is compiled with debug information. It only happens at some classes or points in the code. And I am pretty sure that that part of the code is reached because I can reach it stepping
EDIT: The solution from Richard doesn't work; thanks anyway. I am compiling in Debug, without any optimization.
Could it be that you are trying to set breakpoints in a shared library that has not been loaded yet. That won't work until the library has loaded. Newer gdb allow to set deferred breakpoints, but that may not (yet) be supported by CDT. A workaround is to set a breakpoint in a place that is available from the beginning that will be reached when the shared library in question is already loaded. Then set the other breakpoint in the shared library. Now it should work. It's a bit more tedious, but usually works.
From the GDB documentation:
For a pending breakpoint whose address is not yet known, this field will contain 'PENDING'. Such breakpoint won't fire until a shared library that has the symbol or line referred by breakpoint is loaded.
I have found that sometimes switching the referred Process Launcher from "GDB (DSF) Create Process Launcher" to "Standard Create Process Launcher" has fixed this problem for me. Other times, just deleting all breakpoints and restarting Eclipse does the trick.
"Unresolved Breakpoint" just means that GDB did not find code location corresponding to the file and line on which you attempted to set a breakpoint.
Are you trying to stop in a constructor?
If so, you are likely seeing this cently fixed GCC bug.
Sometimes optimizations will cause breakpoints to be skipped as well. Make sure you're compiling with -O0
I have found that using F8 (resume) doesn't stop at my breakpoints. But, if I have Stop On Startup : main set then then step over my code (F5/F6) then my breakpoints are hit. I don't have any special compiler options other than -g or -g3. Hope that help...
Make sure the breakpoint type is correct. For C/C++ it's a tiny blue dot. If it looks like anything else, chances are the breakpoint type is incorrect. I would try to close the file, right click on it -> open with -> C/C++ Editor. This worked for me.
If other answers here didn't solve your problem, it is possible you are having the same problem I had (which was the result of having an outdated version of GDB). This is likely the case for anyone using GDB on Mac.
See my question and answer here:
GDB does not break on some lines of code when using multiple source files
Do you place a breakpoint in a template class/function? I've met the same problem: I can step through the code of templates but breakpoints do not work.
I guess eclipse does not understand that it has to place breakpoints in all instantiations of that class:
template <typename T>
int doit(T a) {
return a.do(); // <-- breakpoint here
}
...
A a;
cout << doit(a);
I think it will wait for doit(...) and never for doit(...).
At lease gdb itself stops on the breakpoint if I set it to the function: 'doit'.
I had a similar issue with GDB. It seems that it was caused by identical source code filesnames even if they have different paths. I renamed the duplicates and GDB worked just fine after that.
Silviu
i had the same problem,
1.- Removed the breakpoints.
2.- Restart eclipse
3.- Clean the project by using project -> clean
4.- Add again the breakpoints and start your debugging.
This solved my issue.
IF you are using GDB as a debugger, make sure you are using both flags:
-g and -ggdb
You can either edit the make file directly,
FCFLAGS = -g -ggdb (some other flags you might have)
or go to Debug Configuration (It's in the menu that drops down when you click on the little arrow besides the bug icon.) Select the project you are debugging, and click on the debugger tab. Check you are using gdb, and add the flags here.
Amazing that there are so many different answers to this question. There is still (2020) a problem in Eclipse 2019.12, CDT 9.10, RHEL 8.0, x86_64. In my case, I can fix it by adjusting the breakpoint properties, and changing it from 'regular' to 'hardware' (select the breakpoint window, then right-click on the breakpoint, Breakpoint properties, common, type).