From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6670 invoked by alias); 18 Dec 2008 21:04:31 -0000 Received: (qmail 6661 invoked by uid 22791); 18 Dec 2008 21:04:30 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Dec 2008 21:03:55 +0000 Received: (qmail 17522 invoked from network); 18 Dec 2008 21:03:53 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Dec 2008 21:03:53 -0000 From: Pedro Alves To: Michael Snyder Subject: Re: GDB hangs on kill or quit (after following a fork child, not detaching from the parent) Date: Thu, 18 Dec 2008 21:04:00 -0000 User-Agent: KMail/1.9.10 Cc: "gdb-patches@sourceware.org" References: <200812122113.57018.pedro@codesourcery.com> <494AA299.60308@vmware.com> In-Reply-To: <494AA299.60308@vmware.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200812182103.42148.pedro@codesourcery.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00330.txt.bz2 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