From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18673 invoked by alias); 18 Dec 2008 21:26:27 -0000 Received: (qmail 18662 invoked by uid 22791); 18 Dec 2008 21:26:26 -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:25:31 +0000 Received: (qmail 29074 invoked from network); 18 Dec 2008 21:25:29 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Dec 2008 21:25:29 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: GDB hangs on kill or quit (after following a fork child, not detaching from the parent) Date: Thu, 18 Dec 2008 21:26:00 -0000 User-Agent: KMail/1.9.10 Cc: Michael Snyder References: <200812122113.57018.pedro@codesourcery.com> <494AA299.60308@vmware.com> <200812182103.42148.pedro@codesourcery.com> In-Reply-To: <200812182103.42148.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812182125.17188.pedro@codesourcery.com> 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/msg00331.txt.bz2 On Thursday 18 December 2008 21:03:41, Pedro Alves wrote: > 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) > That was a thread-db related issue, which you could claim is a bit undefined for the current checkpoints support. For completeness, here's a non-threaded example showing how following the child behaved: >gdb /home/pedro/gdb/tests/test GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"... Setting up the environment for debugging gdb. Function "internal_error" not defined. Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal] Function "info_command" not defined. Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal] /home/pedro/gdb/baseline/build/gdb/.gdbinit:8: Error in sourced command file: No breakpoint number 0. (gdb) start Breakpoint 1 at 0x40044c: file main.c, line 5. Starting program: /home/pedro/gdb/tests/test main () at main.c:5 5 return 0; (gdb) maint print target-stack The current target stack is: - child (Unix child process) - exec (Local exec file) - None (None) (gdb) set follow-fork-mode child (gdb) checkpoint [Switching to process 28696] checkpoint: fork returned pid 0. Failed to find new fork (gdb) -- Pedro Alves