When I debug with gdb and hit a line with log.Println("WhatEver")
gdb is just on a new blank line. How do I get back to gdb?
Thanks
Related
Is it possible to debug another program in a GDB session without first quitting?
After having set up things like set disassembly-flavor intel and having debugged my first program1, I want to debug another program2 without quitting the GDB session.
The reason is, that I don't want to enter all of the commands, like the one above.
Usually, I first quit the original GDB session and debug program2 using gdb program2, but there must be something smarter?
You can kill the currently running inferior, then use file to select a new program to debug, then run it.
If you find yourself typing the same commands a lot, put them in your ~/.gdbinit. You can also enable history-saving so they will be in the command history when you restart gdb.
I am debugging a program using valgrind and gdb. However I terminate those debugging sessions in a barbaric way… Is it really how it is meant to be done ?
Setting up the debugging session
Following the instructions from the official valgrind website I do the following to run the program :
I run valgrind by entering
valgrind --tool=memcheck --vgdb=yes --vgdb-error=0 ./prgm.run
From another terminal session, I run gdb using
gdb ./prgm.run
I connect gdb to valgrind
(gdb) target remote | vgdb
I run the program from gdb CLI
(gdb) c
So far so good : the program runs in both terminals (the one used for valgrind and the one used for gdb). Then valgrind finds an error, for instance an invalid read, and the program execution is paused.
Terminating the session
At that point, I want to fiddle with my code : perhaps fix something or comment/uncomment stuff from the program's source. As a consequence, the program needs to be compiled anew. A new binary is generated. Following that, I want to stop the on-going valgrind and gdb sessions (that were using the old binary) and start new valgrind and gdb sessions that will use the new binary.
To stop an on-going session, I quit gdb
(gdb) q
Sometimes valgrind notices that gdb is no longer there and quits too. But other times valgrind keeps going even-though no gdb process exist anymore…
In that case I kill the "memcheck-amd64-" process corresponding to my valgrind session. The number of that process is indicated in the valgrind messages e.g. 16195 in ==16195== Invalid read of size 8).
kill -9 16195
A regular kill is not enough : I need to use the -9 option.
I don't think invoking kill -9 is how it is meant to be done… Am I missing something ?
valgrind version : 3.10.1
gdb version : 7.7.1
you can also use the comand
(gdb)monitor v.kill
it was listed on monitor help on gdb.
Just use kill command or simply
k
to get rid of asking use set confirm off in .gdbinit file
The previous answers did not work for me, so I found this which did the trick.
(gdb) info inferiors Should list all inferiors in gdb session, find the one with 'remote target' as its name, take note of the number on the left of it (will be 1 if no other inferiors running in gdb)
(gdb) kill inferiors <number> Replace <number> with inferior number.
(gdb) quit
This is a similar question to sublimegdb can not stop in the breakpoint but nobody answers that one so I decided to open a new question.
I just installed sublimeGDB plugin in my sublime text 3 and set a breakpoint successfully by pressing F9. When I pressed F5 to run, the program didn't stop at the breakpoint -- it just finished running while the GDB view showed up for about 0.5 sec then disappeared.
Here's some output in my console view:
Will write debug info to file: stdout
Running: gdb --interpreter=mi ./ex8
In directory: //Users//jimmy/workspace
Process: <subprocess.Popen object at 0x1037a1110>
pty: 41, tty: None, name: /var/folders/m2/7h27qgr17v1bqyphh7wq6tpw0000gn/T/tmpnvs3afgdb_stdout: broken pipe
GDB session ended
gdb_stderr: /bin/sh: gdb: command not found
gdb_stderr: broken pipe
gdb_stderr: /bin/sh: gdb: command not found
This says: sublime ran /bin/sh, and asked it to run gdb, but no program called gdb was found on the PATH.
It must be that either:
you don't have GDB installed on your system at all, or
it is installed somewhere, but it's not on whatever PATH the sublime invokes /bin/sh with.
An OS X binary runs into a segfault when invoked under Yosemite (prints "Segmentation fault: 11" on stderr), but when invoked using lldb, no segfault occurs, and the program ends with error code 0.
Do you have any idea what the reason might be, that the segfault doesn't occur when using lldb? Is there any way to trigger it there (and stop execution when it occurs, so some debugging is possible)?
Try running your program separately and attaching to it. If your binary is called a.out, you would use the process attach --waitfor command like this:
term1$ lldb
(lldb) pr a -w a.out
term2$ a.out
lldb will poll the process table repeatedly until a.out starts up - when it sees the process, it will attach to it. In the lldb terminal, c (continue) the process execution.
Alternatively, you may have a crash report from your process segfaulting in ~/Library/Logs/DiagnosticReports/. This will show you the backtrace at the point where your binary crashed. You may also want to open Console.app and see if any messages are being logged to console at the point where it crashes.
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.