Does anybody know how so use gdb in emacs?
I am using this command to create my program
/home/cdim/Local/gcc-4.9.2/bin/gfortran -ffree-form -g ./utests/test_gdb.f -o test_gdb
I am going to Emacs Tools then Debugger (GDB). I then click on the run button and nothing happens.
What does test_gdb do if you run it outside of gdb? If it sends no output to the screen then this (i.e., no output) is exactly what you will see when you run it inside of gdb - if you have set no breakpoints. Did you set a breakpoint? And how much nothing happens when you click run? Even if test_gdb produces no output, if all is well you should still see gdb display a notification like
[Inferior 1 (process 12345) exited normally]
Consider test.f:
Program p
Integer :: i = 1
Print *, i
End
I would compile this with gfortran -ffree-form -g -ggdb test.f -o test_gdb.
(From https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Debugging-Options.html#Debugging-Options:
-ggdb
Produce debugging information for use by GDB. This means to use the most expressive format available (DWARF 2, stabs, or the native format if neither of those are supported), including GDB extensions if at all possible.
)
Then, as you said, go to Tools -> Debugger (GDB) (or issue M-x gdb) in emacs and make sure the gdb invocation is using the full path to the executable, e.g. Run gdb (like this): gdb -i=mi /foo/bar/test_gdb. Hit return in that minibuffer.
Now, set a breakpoint in the new *gud-test_gdb* buffer:
(gdb) break p
Breakpoint 1 at 0x4007e1: file test.f, line 3.
Then go to menu entry Gud -> Run.
Esc+x then entern gdb ... and input your application file. it will start gdb in emacs
I solved problem by moving to Trisquel 7.0. Might have been a setup problem.
Related
I'm receiving this gdb error on any code I try to debug any program with gdb. Here's the simplest process that reproduces the error
Create a main.cpp file with this content:
int main(){
return 0;
}
Run g++ -g main.cpp
Run gdb a.out
Inside gdb set a break point at line 2 with break 2
In gdb run the program with run
Output:
Starting program: /tmp/test/a.out
During startup program exited normally.
This is all done with gdb on the command line. I've tried using g++ and gcc with the same result. I'm not really sure where to go from here.
gdb version = 9.2
g++ version = 9.3.0
EDIT: I figured out what is causing the issue, but not how to fix it. The issue seems to be something related to my SHELL variable. I'm currently using xonsh as my shell but when I set my SHELL environment variable back to /bin/bash everything works as expected. Is there anything I can do to fix this while using xonsh? Should I report this to xonsh, gdb, both or neither?
I'm currently using xonsh as my shell but when I set my SHELL environment variable back to /bin/bash everything works as expected. Is there anything I can do to fix this while using xonsh? Should I report this to xonsh, gdb, both or neither?
This might be your xonsh startup problem, or it might be xonsh problem, or it could be that xonsh doesn't do what GDB expects it to do.
Normally, GDB forks / execs $SHELL -c "/path/to/your/exe $args" and expects the $SHELL to exec your program (this is done so shell redirection still works under GDB).
Only after that exec will GDB start setting breakpoints, etc.
If you have some xonsh init-file, which e.g. causes xonsh to exec something else, things could go bad. So I suggest trying to remove any such ~/.xonshrc or whatever it's called file, and seeing whether that fixes the problem.
If it doesn't, it could be that xonsh e.g. forks and execs your binary in a child (grandchild of GDB) instead of doing it directly, or it could be that xonsh doesn't understand the -c ... syntax.
If you don't care about redirection, you could also ask GDB to not use $SHELL at all: set startup-with-shell off. Documentation.
Is there any gcc option I can set that will give me the line number of the segmentation fault?
I know I can:
Debug line by line
Put printfs in the code to narrow down.
Edits:
bt / where on gdb give No stack.
Helpful suggestion
I don't know of a gcc option, but you should be able to run the application with gdb and then when it crashes, type where to take a look at the stack when it exited, which should get you close.
$ gdb blah
(gdb) run
(gdb) where
Edit for completeness:
You should also make sure to build the application with debug flags on using the -g gcc option to include line numbers in the executable.
Another option is to use the bt (backtrace) command.
Here's a complete shell/gdb session
$ gcc -ggdb myproj.c
$ gdb a.out
gdb> run --some-option=foo --other-option=bar
(gdb will say your program hit a segfault)
gdb> bt
(gdb prints a stack trace)
gdb> q
[are you sure, your program is still running]? y
$ emacs myproj.c # heh, I know what the error is now...
Happy hacking :-)
You can get gcc to print you a stacktrace when your program gets a SEGV signal, similar to how Java and other friendlier languages handle null pointer exceptions. See my answer here for more details:
how to generate a stacktace when my C++ app crashes ( using gcc compiler )
The nice thing about this is you can just leave it in your code; you don't need to run things through gdb to get the nice debug output.
If you compile with -g and follow the instructions there, you can use a command-line tool like addr2line to get file/line information from the output.
Run it under valgrind.
you also need to build with debug flags on -g
You can also open the core dump with gdb (you need -g though).
If all the preceding suggestions to compile with debugging (-g) and run under a debugger (gdb, run, bt) are not working for you, then:
Elementary: Maybe you're not running under the debugger, you're just trying to analyze the postmortem core dump. (If you start a debug session, but don't run the program, or if it exits, then when you ask for a backtrace, gdb will say "No stack" -- because there's no running program at all. Don't forget to type "run".) If it segfaulted, don't forget to add the third argument (core) when you run gdb, otherwise you start in the same state, not attached to any particular process or memory image.
Difficult: If your program is/was really running but your gdb is saying "No stack" perhaps your stack pointer is badly smashed. In which case, you may be a buffer overflow problem somewhere, severe enough to mash your runtime state entirely. GCC 4.1 supports the ProPolice "Stack Smashing Protector" that is enabled with -fstack-protector-all. It can be added to GCC 3.x with a patch.
There is no method for GCC to provide this information, you'll have to rely on an external program like GDB.
GDB can give you the line where a crash occurred with the "bt" (short for "backtrace") command after the program has seg faulted. This will give you not only the line of the crash, but the whole stack of the program (so you can see what called the function where the crash happened).
The No stack problem seems to happen when the program exit successfully.
For the record, I had this problem because I had forgotten a return in my code, which made my program exit with failure code.
I am using gdb to debug NS-2 which is a simulator for network protocols. It takes an .tcl file as input and interpret it. [I think it is an interpreter.]
Some of the code is written in tcl (events and creation of network components) and some in C++ (especially Packet Formats, Agents etc.).
I have created an Agent in C++ and i want to stop it at some function call so that i can see the stack trace and find which other classes have been called before it.
This is what i have done:
There was some error in one of my MyAgent::function and it was giving Segmentation Fault and gdb was stopping there automatically. I could then see the stack trace. I rectified the error.
Now when i run
gdb ./ns
b MyAgent::function()
/*
When i press TAB after writing "b MyA" it gives me all functions
of my class :). when i press enter after above command --
it asks me "Breakpoint on future shared library load" and i say Yes.
I hope this is ok ??
*/
r myfiles/myWireless.tcl
Now it runs and do not stop anywhere. :(
I am sure that this function is being called, because when that Segmentation fault was occuring, it was stopping at that function.
Thanks
You can add a breakpoint in that function:
(gdb) break MyAgent::function()
You must make sure to compile with whatever options are necessary to get debug symbols. On GCC, use the -g or -ggdb options.
You need the -args option to specify the tcl script that will be executed.
Run gdb like this:
gdb -args ./ns path/to/tcl/script.tcl
To enable debug flag to c++ code, if have not done it already, re-configure your ns2 instalation with:
./configure --enable-debug ;# plus any other flags you use for configuring
make clean
make -j 3 ;# -j for faster compiling
make install ;# optional
You can also use the --with-tcldebug=..., for debugging tcl code (You need to install tcldebug first for this option)
I have a program running in Linux and It's been mysteriously crashing. I already know one way to know where it crashes at is to use GDB. But I don't want to attach to it every time I restart it (do this a lot since I'm testing it). Is there an alternative way to do this?
First use ulimit -c unlimited to allow crashed programs to write core dumps.
After the program crashes, you'll find a core dump file, called core, or perhaps core.<pid> if your program is multithreaded.
You can load this into GDB to examine the state at the point of the crash with gdb program core.
First do a ulimit -c unlimited, so the program will leave a core dump.
Then, when it crashes, invoke gdb with the core dump, to read the
state of the program at the moment of the crash.
You can configure your OS to dump a core file any time a program crashes. You can then examine the core to determine the crash location.
-> compile the code with gdb flags enabled.
gcc -o < binary name > -g < file.c > (assuming it is a c/c++ program)
-> run the executable withing gdb.
gdb < binary name >
after this there are ways to find the crash location:
1. stepwise execution.
2. run the code, it crashes (as expected), type "where" within gdb (without quotes) it gives the backtrace. from that, you can find out the address.
here is a nice quick guide to gdb : http://www.cs.cmu.edu/~gilpin/tutorial/
I'd like to have gdb immediately run the executable, as if I'd typed "run"
(motivation: I dislike typing "run").
One way is to pipe the command to gdb like this:
$ echo run | gdb myApp
But the problem with this approach is that you lose interactivity with gdb,
eg. if a breakpoint triggers or myApp crashes, gdb quits.
This method is discussed here.
Looking at the options in --help, I don't see a way to do this, but perhaps I'm missing something.
gdb -ex run ./a.out
If you need to pass arguments to a.out:
gdb -ex run --args ./a.out arg1 arg2 ...
EDIT:
Orion says this doesn't work on Mac OSX.
The -ex flag has been available since GDB-6.4 (released in 2005), but OSX uses Apple's fork of GDB, and the latest XCode for Leopard contains GDB 6.3.50-20050815 (Apple version gdb-967), so you are out of luck.
Building current GDB-7.0.1 release is one possible solution. Just be sure to read this.
I would use a gdb-script:
gdb -x your-script
where your-script contains something like:
file a.out
b main
r
afterwards you have the normal interactive gdb prompt
EDIT:
here is an optimization for the truly lazy:
save the script as .gdbinit in the working directory.
Afterwards you simply run gdb as
gdb
... and gdb automatically loads and executes the content of .gdbinit.
(echo r ; cat) | gdb a.out
The cat allows you keep typing after gdb breaks.
start command
This command is another good option:
gdb -ex start --args ./a.out arg1 arg2
It is like run, but also sets a temporary breakpoint at main and stops there.
This temporary breakpoint is deactivated once it is hit.
starti
There is also a related starti which starts the program and stops at the very first instruction instead, see also: Stopping at the first machine code instruction in GDB
Great when you are doing some low level stuff.
gdb -x <(echo run) --args $program $args