[ Michael, you're the forks man. CCing you in case see an issue with the attached patch? ] GDB hangs if you do: > ./gdb -ex "set follow-fork-mode child" -ex "set detach-on-fork off" ./testsuite/gdb.base/foll-fork GNU gdb (GDB) 6.8.50.20081212-cvs (gdb) start Temporary breakpoint 1 at 0x40054f: file ../../../src/gdb/testsuite/gdb.base/foll-fork.c, line 21. Starting program: /home/pedro/gdb/baseline/build/gdb/testsuite/gdb.base/foll-fork Temporary breakpoint 1, main () at ../../../src/gdb/testsuite/gdb.base/foll-fork.c:21 21 int v = 5; (gdb) n During symbol reading, incomplete CFI data; unspecified registers (e.g., rax) at 0x40054b. 23 pid = fork (); (gdb) [Switching to process 14900] 24 if (pid == 0) (gdb) kill Kill the program being debugged? (y or n) y The same will happen if you issues 'quit' instead of 'kill', as quitting tries to 'kill' the inferior. When there are forks involved, linux_nat_kill calls into linux_fork_killall to do the killing. But, when following a fork child, and not detaching from the parent, we defer adding the child fork to the list of forks (which is confusing IMHO, see below), so linux_fork_killall misses killing it. Then, we hang waiting for it to die, but it won't happen. "kill" -> linux_nat_kill -> linux_fork_killall. This kills all forks listed. At this point, since only the parent was listed, the child was left alive. After killing, we call target_mourn_inferior, which goes: -> linux_nat_kill -> linux_nat_mourn_inferior ->inf_ptrace_mourn_inferior Now, inferior_ptid was pointing at the child (we followed it), and, we didn't kill it so, we hang here: 184 /* Clean up a rotting corpse of an inferior after it died. */ 185 186 static void 187 inf_ptrace_mourn_inferior (struct target_ops *ops) 188 { 189 int status; 190 191 /* Wait just one more time to collect the inferior's exit status. 192 Do not check whether this succeeds though, since we may be 193 dealing with a process that we attached to. Such a process will 194 only report its exit status to its original parent. */ (top-gdb) 195 waitpid (ptid_get_pid (inferior_ptid), &status, 0); ^^^^^^^ #0 0x00007fb6a45364a5 in waitpid () from /lib/libc.so.6 #1 0x00000000005df07b in inf_ptrace_mourn_inferior (ops=0xaf4ce0) at ../../src/gdb/inf-ptrace.c:195 #2 0x0000000000477c55 in linux_nat_mourn_inferior (ops=0xaf4ce0) at ../../src/gdb/linux-nat.c:3194 #3 0x0000000000543d82 in target_mourn_inferior () at ../../src/gdb/target.c:1899 #4 0x0000000000477c09 in linux_nat_kill () at ../../src/gdb/linux-nat.c:3180 #5 0x00000000004622b6 in kill_command (arg=0x0, from_tty=1) at ../../src/gdb/inflow.c:602 ... ================= The attached patch fixes it by also adding the child to the fork list in this case. Also, since we're now adding the child, one bit of special casing from linux-fork.c can be removed, as in the patch. The 'error' call in linux-fork.c that I'm removing is really dead code, as all callers do the same check. This is the current output of info forks, when following a parent, and when following a child: ./gdb -ex "set follow-fork-mode parent" -ex "set detach-on-fork off" ./testsuite/gdb.base/foll-fork ... (gdb) info forks 1 process 15396 at 0x7ffff789ac4b, * 0 process 15393 (main process) at 0x40055e, file foll-fork.c, line 24 ./gdb -ex "set follow-fork-mode child" -ex "set detach-on-fork off" ./testsuite/gdb.base/foll-fork ... (gdb) info forks 1 process 15319 at 0x7ffff789ac4b, Notice how the 'following the child' case is a bit convoluted: - Only the parent is listed, but it isn't that obvious that fork 1 is the parent. - There's no indication of which fork is current. If you do: (gdb) fork 1 Switching to process 16458 #0 0x00007ffff789ac4b in fork () from /lib/libc.so.6 (gdb) info forks 2 process 16461 at 0x40055e, file foll-fork.c, line 24 * 1 process 16458 at 0x7ffff789ac4b, (gdb) Voila! - the child fork was added (fork 2). I find this confusing. ================= This is the output after the patch is applied: > ./gdb -ex "set follow-fork-mode child" -ex "set detach-on-fork off" ./testsuite/gdb.base/foll-fork ... (gdb) info forks * 2 process 15934 at 0x40055e, file foll-fork.c, line 24 1 process 15927 at 0x7ffff789ac4b, >./gdb -ex "set follow-fork-mode parent" -ex "set detach-on-fork off" ./testsuite/gdb.base/foll-fork ... (gdb) info forks 1 process 15979 at 0x7ffff789ac4b, * 0 process 15974 (main process) at 0x40055e, file foll-fork.c, line 24 A bit more uniform, and the hang bug goes away, of course. That special casing to have a fork number 0 could go away too, IMVHO. Tested on x86_64-linux-gnu, no regressions. -- Pedro Alves