I created a simple cpp file and compiled it using the cygwin g++ compiler in Win7. I am now trying to debug the resulting executable in gdb, but I can't get it to behave the way I expect it to. I cannot place breakpoints because when I try to execute b file.cpp:25 I get back
No source file named file.cpp.
Make breakpoint pending on future shared library load? (y or [n])
I select y and it still does not break at the expected point. I did compile from this source.
I am getting a segfault at a certain point and whe also does not actually show line numbers. It seems to show memory addresses, which is obviously not useful to me.
Is gdb is misbehaving or am i just expecting it to do things it can't do? If it doesn't have this capability (though I've done this kind of thing before), is there another tool I can use?
In order to add debug information during compilation you should use the -g flag for g++.
Related
I'm working on a project, where I cannot disclose the details of the code. So, the application is all written in C and C++. Since, a particular file which wanted to debug has a lot of dependencies and exports, I need to debug the whole project. How do I set breakpoints in the code itself so that the debugging would stop at that particular point? I'm using Ubuntu 14.04 (since the project is compatible with this environment) and gdb debugger.
I've tried using
#include <csignal>
// Generate an interrupt
std::raise(SIGINT);
But I keep getting error
error: ‘raise’ is not a member of ‘std’
Even this also didn't work
#include <signal.h>
raise(SIGINT);
Plus the debugging wont stop at that point, so that I could foresee the function at that point. I only want to debug it from console, rather using any IDE.
Since the programfile I want to debug has lot many header files which it imports, I'm unable to make a executable to use gdb. So, while make clean build of my MakeFile I want to debug the particular program file at a particular function. So, for that I want to add breakpoints in the program. I cannot use any GUI for debugging since I should not use.
Have you tried to use GDB Commands?
b lineno - set a break point at line 'lineno'
b srcfile:lineno - set a break point in source file 'srcfile' at line 'lineno'
Read more about debugging with gdb. Be sure to compile all your code with DWARF debug information (so use g++ -Wall -Wextra -g to compile it with GCC).
GDB is extensible and you can define your own gdb commands at startup in your init file, probably .gdbinit and put some initial commands there.
BTW, on Linux, debugging (so the gdb debugger) is using ptrace(2) facilities. And you can use gdb non-interactively on the command line, using scripts.
How do I set breakpoints in the code itself
I don't recommend adding specific C code for breakpoints. So don't do that in your C code. But see also this.
Perhaps you want some backtrace library, like Ian Taylor's libbacktrace ?
I cannot use any GUI for debugging
You don't need to. You'll use gdb on the command line. With an appropriate gdb script, you can even use it non-interactively (e.g. in a Makefile)
I only want to debug it from console, rather using any IDE.
Please realize that IDEs are only glorified source code editors capable of running other external tools (including the GCC compiler and the gdb debugger). You certainly don't need -on Linux- any IDE to run a compiler or a debugger (but IDEs could be convenient, but not necessary, for that), because you can (and should) run your compiler, your debugger, your build automation tool, on the command line.
Since the program file I want to debug has lot many header files which it imports, I'm unable to make a executable
You should fix that first. You need to make an executable. BTW, there is no "import" involved at run time, since header files are relevant only at compile time. Read more about the cpp preprocessor. You probably should invoke GCC (e.g. the g++ compiler, since you have C++ code) with appropriate preprocessor options (sometimes, tools like pkg-config are useful for that). You probably should use some build automation tool such as GNU make (with your Makefile; see this for inspiration) or ninja. You could add ad hoc gdb commands to your build procedure (e.g. with some additional and specific rules and/or recipes in your Makefile).
First, make sure you have compiled with -g. There are other gdb specific flags in gcc. You could add them in too.
Try using ddd, the graphical version of gdb. Great tool if you don't know the gdb command line. Just open up the relevant source file, select the line then click on breakpoint on the toolbar. It will tell you on the console section, what command was actually executed (good way to learn). There is a floating button list with run, next etc. for stepping through your code.
ddd will work on most of the gcc toolchain.
EDIT:
Say your code is made up of 2 files main.cpp and child.cpp. main.cpp contains main(). The executable is called a.out.
To start
ddd a.out &
It will open in main.cpp. To put a breakpoint in child.cpp, click on File/Open Source... and select child.cpp. Then scroll to where you want a breakpoint. Put your cursor on the line, then click on break in the toolbar.
To run, either type run in the gdb window below or click on Run in the floating button dialog.
Recently, our development team is starting to use ccache to do faster compile (the compile is done from sandbox /usr/x).
Now, when I compile from my sandbox (/usr/y), and try to set a breakpoint in the code in Eclipse (GDB (DSF) process launcher), it fails to find the file.
Further investigation shows that Eclipse gdb uses the complete path of the file to set a breakpoint (e.g. b /usr/y/untouchedFile.cpp:1234), but the actual path (in the gdb debugger) is actually /usr/x/untouchedFile.cpp.
The only thing that works is to set a breakpoint on the console by typing it, and do a source file mapping when the breakpoint is hit.
I would like to set the breakpoint by clicking on the code line (which used to work before ccache).
I was wondering if there is a way to get around this.
Thanks!
I am using scientific linux. I am dealing with a huge amount of code in C++ with tons of cpp files. Right now, it compiles successfully, but the values/data I'm getting are definitely wrong. Also, for some small changes I make to the code causes seg faults.
In the directory user/project/Build, I enter make to compile and link all the cpp files. I then have to go to user/project/Build/bin/project to run the project binary by typing user/run/run.sh
When I go to directory /user/project/Build/bin and then type gdb project and then run, I see
Program exited with code 01. Missing separate debuginfos, use: debuginfo-install glibc..
If I try to set a breakpoint, such as by break test.cpp:19, I get the message No source file named test.cpp.
Make breakpoint pending on future shared library load?
But I clearly have a source file named test.cpp
How can I set breakpoints? Considering that I'm a beginner with Unix, should I use another IDE such as emacs or Qt creator?
Did you read the documentation of GDB? It is definitely worthwhile to read it. Read also some tutorial on gdb
If your Makefile-s are generated by cmake, you should also study the documentation of cmake and the documentation of make. See also this answer to a related question.
Did you compile all your software with g++ -Wall -g (and without any optimization flags like -O1 or -O2) - or perhaps even -g3 instead of -g?
You might even install debugging variants of the major libraries you are using (e.g. packages like glibc-debuginfo etc...)
You probably want to specify (for gdb) the source directories to search with the dir command of gdb ...
And yes, I recommend using emacs. But above all, I strongly recommend spending hours (and perhaps days or even weeks) to learn more about Linux and software development on it (there are lots of books, websites, tutorials and other training, ... about that). Maybe start with a small, hello-world like, program (learning how to compile it with g++ and to debug it with gdb). Then try to compile and debug a small (e.g. of a hundred thousand lines of source code) free software that you like (e.g. fishshell or anything you've got from sourceforge or github), just to get a feeling of how such software is built.
If you are using (or improving) a big scientific software, it probably has some community website, mailing list, or forum for help (see geant or kiva or aster as examples, which I only know by name!). Please also use them.
PS. It is not mostly a matter of choosing tools: you are using the good ones (GCC i.e. g++, emacs, gdb, make, grep or ack, etags, git, awk, ....). It is a matter to get the knowledge -spending weeks or months of your time- about how to use them wisely and combine their use. See also this & that.
I have a core dump generated by 2 applications -> /usr/bin/python and /usr/bin/app1.
I know the dump can be analyzed by
gdb /path/to/app /path/to/core
but is there a way to include both applications in the arguement?
I did try gdb '/usr/bin/python /usr/bin/app1' core.xxx but that doesnt seem right.
Any suggestions?
I think you cannot achieve what you want with a single invocation of gdb. But you could run gdb twice, in different terminal windows. I did that more than once, and it works quite well (except of course that your own brain could be slightly overloaded).
a gdb process can debug only one single program, with one single debugged process or (for post mortem debug) one single core file.
And a given core file is produced by abnormal termination of one single process (not several), so I don't understand your question.
Apparently, you have a crash in some execution of python probably augmented by your faulty C code. I suggest having a debuggable variant of Python, perhaps by installing the python3-all-dbg package or something similar, then use gdb on it. Of course, compile your C code plugged into Python with debugging enabled. Perhaps you violated some invariant of the Python garbage collector.
What are the 'best practices' when it comes to debugging core dumps using GDB?
Currently, I am facing a problem:
The release version of my application is compiled without the '-g' compiler flag.
The debug version of my application (compiled with '-g') is archived (along with the source code, and a copy of the release binary).
Recently, when a user gave me a core dump, I tried debugging it using
gdb --core=./core.pid ./my_app_debug-bin
The core was created by my_app_release-bin. There seems to be some kind of mismatch between the core file and the binary.
On the other hand, if I try
gdb --core=./core.pid ./my_app_release-bin
the core matches but I am unable to get source code line numbers (although I get the function names).
Is this what is practised? Because I feel I am missing something here.
It sounds like there are other differences between your release and debug build then simply the absence/presence of the -g flag. Assuming that's the case, there is nothing you can do right now, but you can adjust your build to handle this better:
Here's what we do at my place of work.
Include the -g flag when building the release version.
Archive that version.
run strip --strip-unneeded on the binary before shipping it to customers.
Now, when we get a crash we can use the archived version with symbols to do debugging.
One thing to note is that if your release version includes optimization, debugging may be difficult even with symbols. For example, the optimizer can reorder your code so even though the debugger will say you crashed on line N, you can't assume that the code actually executed line N-1.
You need to do some additional stuff to create binaries with stripped debug information that you can then debug from cores. Best description I could find is here
No, you don't miss anything. debug and release are just different binaries, so the core files of release don't match the debug binary. You have to look at machine code to get something from the release core dump.
You probably have to ask your user how the crash happened and collect additional log information or whatever you app produces.