I'm trying to set a breakpoint in gdb to stop before an exit(0) signal. I've tried:
stop sigquit
although the program still exits without stopping. How do I set a breakpoint for this?
Have you tried setting breakpoints on exit or _exit?
If that doesn't work have a look at setting a gdb exit breakpoint not working?
Related
I have a multi-threaded C++ program running on CentOS 5 exhibiting an Exit code 6 which is undesired:
[Inferior 1 (process 22898) exited with code 06]
It should be exiting with 00. I need to debug this issue using GDB. This program is heavily multi-threaded and I'm not sure what code is running on this particular thread.
What's the best (easiest and most effective) way to catch the exit in the inferior process and get a backtrace so I can see where the thread is exiting?
I have tried setting set detach-on-fork off but it just ends up hanging the program.
What's the best way to catch the exit in the inferior process and get a backtrace so I can see where the thread is exiting?
(gdb) catch syscall exit_group
If I run a program under gdb, how do I break at an arbitrary point? Pressing Ctrl+C kills the program. Ctrl+Break does nothing.
I can't enter gdb commands because my program is itself sitting in a REPL loop so anything I enter goes to my program, not to gdb.
My program uses linenoise to implement the REPL; I assume that this is hiding Ctrl+C, etc., from gdb.
Ctrl+\ results in a 001C square blob thingy in my program, rather than SIGUSR1.
Pressing Ctrl+C kills the program.
That is not the default GDB behavior.
Did you set handle SIGINT nostop pass?
You can examine current signal disposition with:
(gdb) handle SIGINT
Signal Stop Print Pass to program Description
SIGINT Yes Yes No Interrupt
Update:
My program is using linenoise for console input. I assume that it has done something to Ctrl+C
If your program is modifying terminal settings, you are going to have a very bad time debugging it from the same terminal.
For example, suppose the program sets no echo, and then hits a breakpoint. I think you would get a (gdb) prompt, but would not see any commands you are typing into GDB.
It seems that you would be much better off debugging this program from a different terminal. Use gdb -p $PID to attach to it from "outside".
I am trying to let my program run continously with GDB.
Currently I have a bash script which starts GDB with my program and when it crashes it prints the backtrace and starts GDB again (endless loop).
Now I added a signal handler for my program which kills specific threads when the handler gets a signal from them. Now I can achieve that GDB does not stop by doing this:
handle SIGSEGV nostop
But this leads me to the problem that I do not get a GDB backtrace which I would like to print automatically without stopping the program (or at least continuing automatically).
Any help would be appreciated!
Continue to use handle to suppress ordinary stops from SEGV. Then set a catchpoint that does what you want:
(gdb) catch signal SIGSEGV
(gdb) commands
> silent # this bit is optional
> bt
> continue
> end
This will print a backtrace on SIGSEGV but not otherwise interfere with normal operation. You may also want handle SIGSEGV noprint.
I'm using gdb to solve a binary bomb as part of a class. Every time we set the bomb off we lose points. I already have a break point on the function that explodes the bomb, but have accidentally stepped past it a couple times already and exploded the bomb. Is there a way to make gdb exit at a specific point rather than just break?
You can attach commands to breakpoints. After you set breakpoint, e.g. #1, do this:
commands 1
quit
end
I am trying to catch floating point exception (SIGFPE) in GDB, not pass it to the process and continue debugging onwards.
I have given gdb this:
handle SIGFPE stop nopass
When a SIGFPE occurs GDB stops at the correct place. The problem is I can't and don't know how can I continue debugging.
I have tried giving GDB
continue
or
signal 0
but it still hangs on the offending line and refuses to continue.
Is there a way to continue debugging after receiving a signal?
I am using GDB 7.5.1, which I have compiled myself and I have also tried with GDB 7.4, which comes with my 12.04 Ubuntu distribution. Both have the same behaviour.
The problem is that when you continue a program after a synchronous signal, it reexecutes the same instruction that caused the signal, which means you'll just get the signal again. If you tell it to ignore the signal (either directly or via gdb) it will go into a tight loop reexecuting that instruction repeatedly.
If you want to actually continue the program somewhere after the instruction that causes the signal, you need to manually set the $pc register to the next (or some other) instruction before issuing the continue command.