This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: GDB hangs on kill or quit (after following a fork child, not detaching from the parent)
- From: Pedro Alves <pedro at codesourcery dot com>
- To: Michael Snyder <msnyder at vmware dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Thu, 18 Dec 2008 21:03:41 +0000
- Subject: Re: GDB hangs on kill or quit (after following a fork child, not detaching from the parent)
- References: <200812122113.57018.pedro@codesourcery.com> <494AA299.60308@vmware.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