I am debugging a code in llvm/lib/.. . I am using debug build of clang. The break point is hitting by executing "clang ... -emit-llvm" command. I am able to attach gdb with it.
When I do step with gdb to move to next line it is taking lots of time. I tried to write a .gdbinit file by skipping all the symbols. But that did not resolve my issue. Please suggest me any ways to improve debugging speed.
It was a VS code C++ extension issue. The issue is reported below :
https://github.com/microsoft/vscode-cpptools/issues/2901
At the time of answering this post the issue was not yet fixed. So as a work around I used "CodeLLDB" extension from VS code to use LLDB as debugger and stepping was very fast.
Related
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.
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.
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.
I'm debugging some Fortran code with gdb and it keeps stepping through the C code for intrinsic Fortran functions. For example if I try to step past a write call, it jumps into write.c. Is there any way to stop this behaviour? I'm on CentOS 6.3, with gdb 7.2 and gfortran 4.4.
Normally I think "next" should work. But I don't know Fortran, maybe something funny is going on.
Another way is to ensure that you don't have debug info for the intrinsics installed. gdb will automatically skip over functions that don't have debuginfo if you try to "step" into them.
The final way is to upgrade your gdb and use the new "skip" command, which was added exactly for this use case.
I had a problem like this where next wasn't working when I was remote debugging on a cross-compiled target. I finally realized that I had loaded the wrong executable/symbol table using gdb's file command. Hitting next was jumping in to places un-releated to the current line of code. It was doing the best it could given the information I gave it :)
I'm really lost in here. Maybe some of you can point me to a right direction.
I'm developing a tool in ANSI C using GCC over MinGW. The tool is to be run only from command line. Probably only on windows machine. It elaborates some data locally and generates files for use by other programs. Basically it does a lot of math and a few file handling. Nothing really fancy. I didn't find it necessary posting the whole 1000+ lines here for examination...
I compile it with GCC -ansi making sure not even a single warning is present. Everything worked always well as the development evolved. But recently I started getting (almost) random segfaults. I checked for the last changes made, but found nothing. I removed the last changes completely coming back to when it perfectly worked. Still segfaults. I traced line by line. I went back to read and re-read the whole code searching for possible pointers/malloc errors. I simply can't find the reason for it to fail so often and so randomly.
So here is the strange thing - I compiled it with -g and run through GDB.
start MSYS
change dir where the program resides
$ gdb generatore.exe (the one compiled -g that fails)
$ run
And it perfectly works inside GDB. I went step by step. Line by line. Perfect. I tried stressing it with huge amounts of data. All works. Can't reproduce the error. But if the same executable is run from command line, it fails.
I suspect an unpredictable behavior with some pointer but I cannot find it anywhere.
Has anyone ever encountered anything similar? Where should I be checking? Also, I am not as familiar with GDB, since it runs smoothly, can I enforce the control somehow to find the reason it fails? Are any other free debugging solutions for windows you can advise me? How can I debug for unpredictable behaviors?
Thanks a lot for your attention,
maxim
There is a great free tool for catching all kind of runtime errors to do with pointers, memory allocations, deallocations, etc., which cannot be caught at compile time, so your compiler will not warn you about them: valgrind http://valgrind.org/. The problem is, AFAIK it doesn't run on Windows. However, if your program is pure ANSI C you should be able to build it and run it with valgrind on a Linux box.
I'm not 100% sure about it, but it should run OK in a virtual machine, so if you don't have a separate Linux computer you can try installing e.g. Ubuntu in Virtual Box or VmWare and try running your program with valgrind in it.