While using GDB MI instruction I found that in case a program forks to create child process it starts debugging the last child only. So if I try to debug break in parent it does not breaks at that point:
I found this valuable reference in stackoverflow.com:
How do I debug the child process after fork() in gdb?
My question is that how I can set the follow-fork-mode mode and via which GBD MI API?
http://src.gnu-darwin.org/ports/editors/setedit/work/setedit/libmigdb/doc/reference.html
It would be something like 123-gdb-set follow-fork parent.
But you can also look into something like:
gdb-set detach-on-fork off
Related
I'd like to to debug a multiprocess C++ project with GDB, specifically I'd like to know if there is a way to achieve the following
Attach multiple processes to a single instance of GDB while letting all the processes run
Setting up a breakpoint in the source code of one of the processes stops all the attached processes
The ideal solution would be something similar to what is offered by the Visual Studio debugger as described here.
At the moment I'm able to attach multiple processes to a GDB instance but then only the current selected inferior is executed while the others are stopped and waiting for a continue command.
In order to be able to run inferiors in the background, one needs to issue this gdb command
set target-async on
after start up and before running anything. With this option in effect, one ca issue
continue&
(or just c&) and this will send the inferior to the background, giving an opportunity to switch to run another one.
Stopping all inferiors at once is a bit more difficult. There is no built-in command for that. Fortunately gdb is scriptable and it is possible to attach a script to a breakpoint. Once the breakpoint is hit, the commands are executed. Put inferior n and interrupt commands in the script for each inferior. It is probably more convenient to do that from a Python script, something like
(gdb) python
>inf = gdb.inferiors()
>for i in inf:
> gdb.execute("inferior %d" % i.num)
> gdb.execute("interrupt")
I start gdb as following: gdb --args parentExecutable LotsOfArgsForParent
I also run: set follow-fork-mode child
parentExecutable forks at some point and executes a childExecutable with some arguments. I debug the child for a while. Then, I use the run command of gdb to restart the parentExecutable with the arguments given in the beginning. However, instead, the childExecutable restarts -- from scratch without any arguments. How can I make gdb start the parent with the arguments provided in the beginning?
There are actually two modes to pay attention to in this scenario. One mode is follow-fork-mode, which tells gdb what to do when the inferior forks. However, there is also follow-exec-mode, which tells gdb how to handle an exec call.
The default setting for follow-exec-mode is same, which tells gdb to reuse the current inferior for the exec'd process. In this situation, once the child process stops, run will re-run the child.
What you want, instead, is set follow-exec-mode new. In this mode, gdb will make a new inferior in response to the exec. Then, when you want to re-run the original executable, you can switch back to the first inferior (use info inferior to get a list and the inferior command to select one). Then run will re-run the original.
Another way to do all this is multi-inferior debugging, using set detach-on-fork off. However, in my experience, this mode is still a bit flaky. Once it works, though, I think it will be the preferred approach.
What I'd like to know is if it is possible, inside a debugging session in Linux, (read: gdb :)) to stop the execution of a single thread, leaving the other threads to run.
If someone is curious to know why keep reading:
I wrote a software watchdog C++ class (using Qt). I tested it with a simple multithreaded program, but I'd like to test the code once I integrate it inside the real application as well. If I could stop a thread from the debugger, that will simplify this testing phase. :)
Cheers
Sergio
Use this sequence of commands before you run or attach to your program:
Enable the async interface:
set target-async 1
If using the CLI, pagination breaks non-stop:
set pagination off
Turn it on:
set non-stop on
Use these commands to manipulate the non-stop mode setting:
Enable selection of non-stop mode:
set non-stop on
Disable selection of non-stop mode:
set non-stop off
Show the current non-stop enabled setting:
show non-stop
References:
http://sourceware.org/gdb/onlinedocs/gdb/Non_002dStop-Mode.html#Non_002dStop-Mode
You may use totalview debugger to do that
If that little variation is OK, you could send the thread a STOP signal (not as a gdb command the gdb - that the variation) and debug everything else running. Signal CONT lets the thread continue.
To learn a bit more about FreeBSD and *nix systems in general, I'm starting to look at the binaries from the DEFCON 17 Capture The Flag game. Right now, I'm reversing the tucod binary. Here's some possibly useful information on tucod:
tucod: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.2, dynamically linked (uses shared libs), FreeBSD-style, stripped
Some other possibly useful information gained from some brief static analysis is that tucod binds on port 0xDEAD (cute, eh?) and if you give it a specific password ("HANGEMHIGH!") it will play a game of hang-man with you.
The problem that I'm encountering is that I'm not hitting my breakpoints in gdb. Specifically, the breakpoint that I'm trying to reach is in the code that handles the client connection. Without breakpoints, the code executes as expected. When I set a breakpoint on that code, the child exits (instead of breaking into gdb, as expected). If I set breakpoints before the server forks off the child, I can hit those fine but after hitting "continue" the child does not continue to process my connection (that is, it won't ask me for a password or play hang-man).
Since the daemon forks when it receives a new connection, I try to tell gdb to follow the child with this command:
(gdb) set follow-fork-mode child
But after single-stepping the instructions after the fork, it appears that this isn't working.
I've tried looking for calls to signal, thinking they implemented a custom SIGINT handler (or similar), but the only call to signal that I can see handles SIGCHLD.
My breakpoint in gdb currently looks like this:
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x080497d0
And 0x080497d0 is the address I want to break on in the client processing code.
I'm sort of new to analyzing software on *nix systems and could use some pointers. How else should I go about troubleshooting why GDB will not hit my breakpoints? Or is there something major I'm just overlooking?
There's a torrent available with all of the game binaries for those interested in seeing the binary first-hand.
Look here for the answer. In short, it looks like GDB supports child debug mode only on HP-UX and Linux.
How do I stop a GDB execution without a breakpoint?
Just use a regular interrupt Ctrl-c will work just fine. GDB just forwards the SIGINT to the debugging process which then dies. GDB will catch the non-standard exit and break the process there, so you can still examine all the threads, their stacks and current values of variables. This works fine, though you would be better off using break points. The only time I find myself doing this is, if I think I've gotten into some sort of infinite loop.
GUI applications don't react to ^C and ^Break the way console applications do. Since these days most non-trivial projects tend to be GUI applications or libraries primarily used in GUI applications, you have two options:
Send SIGSTOP to the application from a separate terminal. This is cumbersome.
If you press ^C or ^Break on the GDB prompt, GDB will terminate but the application will remain running. You can then run GDB again to attach to it using the -p command-line switch. This loses debugger state.
In both cases, you might find this helpful: tasklist | grepProcessName| sed -e 's/ProcessName*\([0-9]*\).*/gdbModuleName-pid=\1/' > rungdb.sh You can modify this for use in shell scripts, makefiles or to send a signal instead of attaching GDB.
info threads will help you figure out which thread you want to look at. Then use threadThreadNumber to switch to it.
Start a shell, find the process ID using ps and send it SIGSTOP or SIGINT by using the kill command (e.g. kill -INT pid).
Just type BREAK without any arguments.
Break, when called without any arguments, break sets a breakpoint at the next instruction to be executed in the selected stack frame
Ctrl + Z seems to work for me (but only in some cases - I'm not sure why).