So, I have no idea why, but breakpoints in my code::blocks project are no longer working. I'm using MinGW-W64 compiler and GDB. I used to be able to use breakpoints, but now, for some reason, when I add them to my code they do absolutely nothing - code execution goes right past them without stopping.
Why might this be happening?
You might be compiling your code in release mode. Try changing it to debug mode. Checkout http://wiki.codeblocks.org/index.php?title=Debugging_with_Code::Blocks on how to turn on debugging symbols.
Related
Within QtCreator, in an Ubuntu machine, I want to debug a C++ application.
I make a debug build by adding -DCMAKE_BUILD_TYPE=Debug argument to the CMAKE part of the build settings. I set a breakpoint and I start debugging. The breakpoint is hit, but instead of stepping through the code linearly, the program counter (PC) keeps jumping around like it I was trying to debug optimized code, yet it's a debug build. The program is multi-threaded but I've verified that while debugging I am in the same thread, and yet the PC keep jumping to lines unrelated to the code.
Why could this happen? how to avoid it?
I suspect if this behavior may be related to another question I made a while ago debugging with gdb. Unfortunately, the question went unanswered and I'm not sure why this happens.
Whenever I try to debug TensorFlow's C++ code with Eclipse + GDB, I get GDB crashing, or actually exiting with: error code = -1.
As long as I don't set a breakpoint in TensorFlow's C++ code, the program runs just fine. But when I do, and when the debugger gets to the breakpoint, it crashes after a few seconds with error code -1. There is nothing meaningful in the GDB traces which can explain this behavior.
The GDB version I am using is 7.7.1, running with Eclipse Neon under Ubuntu 14.04.
TensorFlow is compiled in debug mode. I don't think that Eclipse is missing the debug symbols for it, as it is not complaining that those are missing (and also, occasionally, the debugger is able to step through a few steps in the code before it crashes).
An easy way to reproduce is to try and debug the label_image example:
https://www.tensorflow.org/versions/r0.11/tutorials/image_recognition/index.html
Compile it and then create a 'C/C++ Application' debug configuration in Eclipse, directing it to the compiled binary of the label_image app.
I've encountered the same problem with GDB on macOS. But, I finally succeeded to debug tf with lldb. And I also found that using VisualStudio Code + lldb makes it easy for debugging.
Here is my way of debugging. Maybe you can give it a try.
I have a program that I have written in C++ under linux (Ubuntu 10.10).
The programming and debugging worked perfectly until the moment I added the following lines to the code:
mapfile = fopen(map_filename,"wb");
fwrite(map_header,1,20,mapfile); // <-- this is the problem line
fclose(mapfile);
After I added those, the program compiles ok, but the debugger now won't start. It immediately fails with this message:
Program completed, Exit code 0x177
error while loading shared libraries: unexpected PLT reloc type 0xcc
And if I remove the line with the "fwrite", the debugger will start normally.
This problem only happends inside Netbeans.
When I debug it using the command-line "gdb" it also works ok without any problems.
Anyone have idea why its happening and how to fix it?
P.S: Those problems started recently so I assume maybe it has to do something with system updates, I'm not sure.
Found the problem:
Not long ago, I removed some old C++ projects from netbeans. It figures out that netbeans (at least v7.0) remembers all the breakpoints that I put on old projects that don't even exist in the IDE anymore.
I found this by looking at the Debugger Console (Window->Debugging->Debugging Console) and seeing that when "gdb" starts, it tries to setup all these breakpoints from other projects or from projects that do not exists (this is a bug in netbeans, btw)
The solution: I simply cleaned all the breakpoints (inside Window->Debugging->Breakpoints) and now the program can be debugged properly.
Hope this will help to anyone out there who has the similar problem.
i am debugging c++ with eclipse on a linux VM.
The eclipse I am using is Kepler Service Release 1.
I compile the files using Automake.
When I try to debug in Eclipse and do stepover it sometimes jump to backward lines, sometimes it goes into the line. Also when there is a problem it just shows nothing. When I try to see variables it doesn't always succeed. It seems the Eclipse behavior is not so good.
I come from Windows programming and it looks very much like I saw when we compiled release version and tried to debug it in Visual.
Can anyone plesae assist? I can't debug like this. Is there any configuration? something I do wrong?
Thanks
As Martin James stated all I needed was to turn off all optimizations.
I had -o2 flag and needed to remove it.
There are a number of errors going on here but I'm sure they are all linked, so first off I'm getting Access violation reading location exceptions at locations (generally near 0x00000000)
but I only get these exceptions in release and not in debug, even if i setup debugging to do so. Also I found where the error happens but when I step over that it goes in to a complete unrelated function that is not called in the line or in any of the functions in that line of code. But when similar code is called it still goes to this unrelated function but doesn't fail. This all only happens in release versions. I know which piece of code is causing the error as if I comment it out its all fine. Also in the watch window in release all the numbers are wrong most of the time, which has never been a problem but it could help also a added some code to it to output the values of variables to a file and the variables are all fine, the pointers are sensible, but when the exception happens it always says their 0x00000020 but when I look at the log they are fine. This is in 32 bit , but on 64 bit windows 7 in c++. Please any help would be good!
Visual Studio's debugger will cause the program to use a debug heap that can hide uninitialized memory if you use the option "Start with Debugging" to start your program, in release or debug. You can try to run your program built in the Debug configuration without the debugger attached, and then use the Attach to Process... option in the debug menu to attach to your executable.
If this doesn't help, I recommend using windbg to debug your program. For help getting started with windbg, take a look at the answers on this question.
Once windbg is configured and symbol paths are set up, you can use the "!analyze -v" option once the program crashes to get a lot of information about the crash automatically.