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 :)
Related
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.
I'm working on a relatively old Centos system where I am restricted in the packages I can install. I needed a newer version of gdb, so I built that successfully from source in my home dir. This gdb steps through my code fine, but I am looking for trouble that is manifesting in the C++ allocator (mt_allocator.cc) and this new version of gdb can't step through that code. I can break successfully on a function there:
break '__gnu_cxx::__pool<true>::_M_initialize()'
but when that breakpoint hits and I try to step through the code, gdb tells me:
Single stepping until exit from function _ZN9__gnu_cxx6__poolILb1EE13_M_initializeEv,
which has no line number information.
I tried using the dir command within gdb to add the path to where mt_allocator.cc is, but that had no effect.
What do I need to tell gdb so it can find those files?
Ah, found it. The Centos package manager put the debug files for the STL code at /usr/lib/debug. So:
set debug-file-directory /usr/lib/debug
within gdb gets it done.
I'm running a c++ program from R using Rcpp and RcppArmadillo. My OS is windows 8. I use the cxxfunction to compile my code (Later I'll make a package directly instead, but for now I'm clueless about how to make a package). The issue is that R often crash while running my c++ code. There must be some segmentation faults because often it doesn't exactly crash at the same spot even with the same seed. Currently, I'm printing out stuff to the prompt but I feel like this is not the most efficient way to debug my program.
So I read a bit about how to debug c++ code in R and it seems that gdb is a good way to do it. So I downloaded mingwin32 which contains gdb for windows. When I run R using gdb it works fine and I can run all my code fine but when R crash gdb backtrace function returns 'no trace'. I have no idea why. I heard people say to add the option -g -Oo in the compilation, but I'm using cxxfunction to compile my c++ program and I don't know how to compile manually things in R. I also heard some people talk about changing cxxflags but I don't really understand what that is and how to change it.
So my questions are :
Should I use gdb or something else?
How do I get gdb to work with my R program?
Should I install linux on a separate partition to make everything simpler?
Thanks for the help.
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.
Does anyone know a good debugger for C++ segmentation errors on the Linux environment? It would be good enough if the debugger could trace which function is causing the error.
Also consider some techniques that do require from you code changes:
Run your app via valgrind memcheck tool. It's possible to catch error when you access wrong address (e.g. freed pointer, not initialized) - see here.
If you use extensievly stl/boost, consider compiling with -D_GLIBCXX_DEBUG and -D_GLIBCXX_DEBUG_PEDANTIC (see here). This can catch such errors as using invalidated iterator, accessing incorrect index in vector etc.
tcmalloc (from google per tool). When linking with it's debug enabled version, it may find memory related problems
Even more ...
GDB! what else is available on Linux?
Check this out for starting up with GDB, its a nice, concise and easy to understand tutorial.
GDB is indeed about the only choice. There are some GUI's but they are allmost all wrappers for gdb. Finding a segfault is easy. Make sure you compile with -g -O0 then start gdb with your program as argument.
In gdb type run
To start your program running, gdb will stop it is soon as it hits a segfault and report on which line that was. If you need a full backtrace then just type bt. To get out of gdb enter quit.
BTW gdb has a build in help, just type help.