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).
Related
This might be a newbie question, but I am going crazy already haha.
symptom
I am having an issue with the lpcxpresso54102 Dev Board, where I am not able to access main.c during debug session, but if I check on the disassembly window I can see the main file, instruction set and actually the project works and I am able to set breakpoints through disassembly. disassembly_data
symptom
If I place a break point on main.c, when I start the debug session, my breakpoint is replaced by a circle with a exclamation point inside the circle. Browsing through ARM dev QA site, I was able to find that this issue is related to
NO CODE AT BREAKPOINT: A breakpoint could not be set because there is no code generated for this source code line. Compiler or linker optimization can remove unnecessary source code.
ARM_DEV_QA
NOTE: optimization config. was modified from original project to 0 optimization level.
symptom
Once I enabled the option for debug information on the target configuration, the file "startup_LPC54102_cm4.s", the cursor was actually going trough the file and eventually reaching the infinite loop used to toggle the led on the board.
NOTE: This file is the example code from the SDK example lib from NXP (blinky), but all the other examples behave the same in UVision, but if I tried on MCUXpresso IDE the debug session works just fine.
Also I checked the linker files and they seem to be ok.
I changed the configuration on the target of Uvision enabling the output info and also changing the optimization to level 0, checked the compiler control string on C/C++ tab and it seems that all the files path and controls are there (no completely sure though). I tried with external and internal debug HW, same behavior.
When press the Run button in GoLand, it will recompile the code even without any change for the code, why?
This is done by the Go compiler and it should be very fast if nothing changed, thanks to the compiler cache introduced in Go 1.10.
And the reason the recompilation step is required is simple: there is no simple way to tell if indeed nothing has changed or not in the build as external resources outside of the compilers reach could affect the results.
So, the IDE invokes the compiler first, then it starts the debugging process.
A better question would be: what are you trying to do and why is the recompilation a problem in this case?
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
Im working on Arduino Uno board recently im stuck with my code, i couldnt debug using print() in ArduinoIde.So i downloaded AtmelStudio 6.2 for debug purpose.
when i set the breakpoint and try to build .Im getting the warning
The breakpoint will not currently be hit. Unable to set requested breakpoint on target.The current selected deviceis unable to set breakpoints during runtime
please help me sort this issue
Following workarounds worked with the same problem using ATMega 168P on Atmel Studio 7 with Atmel-ICE.
1. Assembler
Insert the following assembler code where you want your breakpoint:
asm("break");
Please note, this is a really ugly solution and not suitable for all situations. It only works with DEBUGwire and makes your program stop in any case, even if no programmer is attached.
2. Create new project
Creating a new project at a different location helped as well. I copied all the required files to the new folder. The new location has a short path (C:\atmel\project...) and contains no spaces, no umlauts etc.
I had a similar problem, the difference was that I could only hit breakpoints in the original modules of my project (i.e. those already existent when I created the .cproj), any modules I added later wouldn't have the program stopped in breakpoints placed on them.
The solution (2) mentioned by #pafodie worked to solve this, but in the process I found a simpler way: just delete the .atsuo file. It will later be automatically recreated, and the problem disappears (at least until you add more modules). It seems AS6 caches something there that isn't updated when new files are added, or does it incorrectly.
I might've found a solution that works, for me at least! You need to disable compiler optimization. In Atmel Studio,
Hit Alt+F7 > ToolChain > Optimization {there are 2 Optimization
windows but only one fits the shoes} > Optimization level > None
I found it here, explained better than I did: https://www.microchip.com/webdoc/GUID-ECD8A826-B1DA-44FC-BE0B-5A53418A47BD/index.html?GUID-8FF26BD2-DBFF-48DD-91FB-8585D91A938D figure 5
If using external Makefile, make sure the -g (debug) flag is set in CFLAGS.
Otherwise, Atmel Studio would have no idea how the source files correspond to the compiled binary.
This happens to me pretty often. For example, right now I have the debugger stopped at a breakpoint in a method . . . and it isn't displaying any variable values at all. Other times, it displays some, but not others.
Can anyone explain?
The most common reason for this is that you're trying to debug code compiled with optimisation enabled and/or no debug symbols. Typically this will be because you're trying to debug a Release build rather than a Debug build but it can also happen with Debug builds if you've made inappropriate changes to the Debug build settings.
Another less common possibility is that you've hosed the stack.
I had this issue (using Swift), I spent ages crawling through my git commits to find where to problem started.
For me, I was using Facebook Tweaks library, but I was (unnecessarily) importing it from my project-bridging-header.h file.
Once I got rid of it, I got my debugging back.
for example, in my bridging header I had:
#ifndef PROJECT_Bridging_Header_h
#define PROJECT_Bridging_Header_h
// Facebook Tweaks
#import "FBTweak.h"
#import "FBTweakStore.h"
#import "FBTweakCategory.h"
#import "FBTweakCollection.h"
#import "FBTweakViewController.h"
#import "FBTweakShakeWindow.h"
#endif
I removed all the imports and just imported it as usual in my AppDelegate import Tweaks.
e.g:
#ifndef PROJECT_Bridging_Header_h
#define PROJECT_Bridging_Header_h
// Removed Facebook Tweaks
#endif
and in my AppDelegate.swift
import Tweaks
This fixed all my debugging issues, everything works as expected and I can also using Facebook Tweaks.
Note: I don't think this is an issue with Facebook Tweaks itself, you may have some other library causing the same issue. The idea is to remove things from your bridging-header one by one and see if you can narrow down the issue.
I think I read somewhere that if a library is causing many issues behind the scenes, this can stop your debugger working.
If this doesn't help, try crawling through your git commits and see at what stage the debugging stopped.
other similar issues on SO:
Xcode Debugging not showing values
Xcode debugger doesn't display variable information after installing CocoaPods Podfile
If you're having similar issues hope this helps! 👍
A possible solution is to set the Optimization Level for your current target Debug scheme to none.
Project -> Target -> Build settings -> Optimization level -> Debug (or whatever fits your project) -> None
Source:
https://stackoverflow.com/a/14948486/3590753
I've had similar issues using LLDB. Switching it back to GDB seems to address it. Obviously this isn't solving the problem, but its a workaround anyway
My issue was that I had address sanitizer enabled. Disabling sanitizer resolved my issue in XCode 8.2.1
You can get the value of any variable in the console by writing:
po name_of_an_objectCVar
or
print name_of_a_cVar
If your breakpoint has "automatically continue after evaluating options" set, then it won't write to the variable view - FYI
I know this is old, but i ran into same problem too. I could not see any summaries of any objects, just types and some address code. After 4 hours of struggling with compilers, debuggers and other solutions i was about to give up when by accident i found this option in debugger. "Show Summaries". Just by clicking it everything got fixed and now i see all variable summaries!
Had the same issue using Xcode 6.4 running the app on device. Running on simulator will show all variables on debugging variables panel.
There is a situation I have seen where Xcode can't cope with return value optimisation (RVO) -- if the compiler decides to apply RVO to a variable then it may not appear in the variables list. You can disable this in g++ and clang with the compiler flag -fno-elide-constructors
See also Understanding eliding rules with regard to c++11
For Swift mix OC Project which use pod
Fixing it by removing useless header(that import with framework by pod) xx-Bridging-Header.h
eg.
In the past I import header with #import "GCDAsyncSocket.h" which I was added in podfile
platform:ios, '8.0'
use_frameworks!
target "roocontrollerphone" do
pod 'CocoaAsyncSocket'
end
just remove it in that xx-Bridging-Header.h file
If you are using the #property feature of Objective-C 2.0 the debugger does not display those variables unless they are backed by explicit ivars in your Class interface. This is slated to be fixed in Xcode 4 as I understand it.
temporary solution when it happpen to me :
right click on the property
jump to definition (u can do it manually and scroll to the #synthesize in the top of the file)
now, if the line is like this :
#synthesize myObject = _myObject ;
set the mouse cursor on the "_myObjects". that what worked for me..when i have problems.
I figured out why it is not working in XCode 4.6 - all of the variables in my object, self, were declared in the .m file instead of the .h. When I moved one of them back to the .h file, it showed up in the debugger. Sounds like a bug with XCode in that it cannot "see" variables declared in the implementation file.
For me it works changing the content of display variables panel to Local Variables and then back to Auto.
This solution worked on XCode 6.3.2, Swift type project.
You need to disable two types of build optimizations in the build settings. By default, the "swift compiler - code generation" optimization level for debug build is set to fast. You need to set this to none. Also check that the "apple llvm 7.1 - code generation" optimization is set to none for debug build.
Finally, check that you are building the debug build in the "architectures" section of your build settings.
Hope this helps.
I have been stuck a while with this problem and finally find out a solution.
I think that many reason can causes this bug but in my case here is the solution.
While you are in the breakpoint position check the included classes.
I was including using double quote a file which was located using include path.
#include "MyClass.h"
instead of
#include <MyPorject/MyClasses/MyClass.h>
So if you have this problem try to double check your inclusion and import.
I know it seems weird but worked for me and I have been able to reproduce it by putting back the Double-Quote include.
One possible reason for the debugger displaying seemingly wrong values is that the variable type is of Any?.
E.g.
var a: Any? = 12
var b: Int? = a as? Int // b=13483920750
var c: Int = a as? Int ?? 0 // c=1
In the example above, b holds the correct value of 1 even though it is not displayed as such.
I've had the same issue and I fixed it by reinstalling all Pods. Just delete them and install again.