ALL,
I'm trying to find a memory leaks in my software written in C++. Everything is written and compiles fine when I try to run the build.
However, when I try to do "Product->Profile", the compilation fails. The compiler couldn't find some header file.
What is wrong and how do I fix it?
TIA!
Check the Scheme. Product -> Scheme -> Edit Scheme or Command <. See what's different within them.
Another place to look is Project Settings: General -> Linked Frameworks or something under Build Phases.
I find that Swift is quick to mark down changes i make as compiler errors in the side panel, and then when i compile, it decides i am right after all. Is Swift just pessimistic about my code?
Can I get the compiler to wait for me to finish the line before declaring it wrong?
There is nothing pessimistic. Xcode uses the same tool - the compiler - to get the errors. However, it usually compiles only one file, using cached compiled objects for the other files. It also doesn't invoke the compiler after every change in your code, so errors that are already fixed can stay there in the side panel.
Building the project fully forces Xcode to refresh the cache and get the current list of errors from the compiler. I do agree that Xcode has many imperfections and this is one of them. When you can't find an error, just rebuild the project.
Note that IDEs for other languages often rebuild the project automatically to solve such problems. This is currently not an option in Swift because it would take too much time.
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.
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...
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).