Re: GDB hangs on kill or quit (after following a fork child, not detaching from the parent)

[Pedro Alves <pedro at codesourcery dot com>]

On Thursday 18 December 2008 19:20:57, Michael Snyder wrote:

> > 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),
> 
> Do you have any intuition as to why we did that?
> I don't remember.  Could it have been related to the
> checkpoint case?
> 
> Otherwise it could simply have been an oversight...

Yeah, I should have mentioned it before:  At first I also
thought it was checkpoints related, then I noticed that
when 'set follow-fork-mode' is child, checkpoints are broken
for other reasons.  It may well be that it always was (broken):

gdb-6.8:

 (top-gdb) set follow-fork-mode child
 (top-gdb) start
 Breakpoint 3 at 0x4509a7: file ../../src/gdb/gdb.c, line 28.
 Starting program: /home/pedro/gdb/baseline/build/gdb/gdb
 [Thread debugging using libthread_db enabled]
 [New Thread 0x7ffff7fd36e0 (LWP 24392)]
 [Switching to Thread 0x7ffff7fd36e0 (LWP 24392)]
 main (argc=1, argv=0x7fffffffe3f8) at ../../src/gdb/gdb.c:28
 28        memset (&args, 0, sizeof args);
 (top-gdb) checkpoint
 warning: Can't attach process 24400: Operation not permitted
 /build/buildd/gdb-6.8/gdb/linux-thread-db.c:302: internal-error: thread_get_info_callback: Assertion `thread_info != NULL' failed.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n)  

HEAD:

 (top-gdb) start
 Temporary breakpoint 3 at 0x4509a7: file ../../src/gdb/gdb.c, line 28.
 Starting program: /home/pedro/gdb/baseline/build/gdb/gdb
 [Thread debugging using libthread_db enabled]

 Temporary breakpoint 3, main (argc=
 During symbol reading, incomplete CFI data; unspecified registers (e.g., rax) at 0x45099c.
 1, argv=0x7fffffffe3f8) at ../../src/gdb/gdb.c:28
 28        memset (&args, 0, sizeof args);
 (top-gdb) set follow-fork-mode child
 (top-gdb) checkpoint
 [Switching to Thread 0x7ffff7fd36e0 (LWP 24520)]
 ../../src/gdb/regcache.c:359: internal-error: regcache_cpy_no_passthrough: Assertion `src != NULL && dst != NULL' failed.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n) 

( this one is related to the fact that moving the infrun context
from the parent to the child isn't complete, so not completelly
checkpoints related... )

Notice that the checkpoints test never sets
follow-fork-mode to child, so this patch can't affect it.

I think that when checkpointing, we should always "follow"
the parent anyway; and that the checkpoints support should be
better insulated from the multi forks support, so that the
multi-forks support can grow into full multi-process support.

> I like your results, and your code changes look fine.
> Can you confirm that it doesn't adversely affect the
> checkpoint testsuites?

Yep, had done that.  No regressions in the checkpoints tests, or in
the rest of the testsuite.

I'll go check it in then.

Thanks!

-- 
Pedro Alves