From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24028 invoked by alias); 15 Jul 2010 22:22:35 -0000 Received: (qmail 24016 invoked by uid 22791); 15 Jul 2010 22:22:34 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from e24smtp03.br.ibm.com (HELO e24smtp03.br.ibm.com) (32.104.18.24) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Jul 2010 22:22:27 +0000 Received: from mailhub1.br.ibm.com (mailhub1.br.ibm.com [9.18.232.109]) by e24smtp03.br.ibm.com (8.14.4/8.13.1) with ESMTP id o6FMLLoT014928 for ; Thu, 15 Jul 2010 19:21:21 -0300 Received: from d24av05.br.ibm.com (d24av05.br.ibm.com [9.18.232.44]) by mailhub1.br.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o6FMRIKw708874 for ; Thu, 15 Jul 2010 19:27:18 -0300 Received: from d24av05.br.ibm.com (loopback [127.0.0.1]) by d24av05.br.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o6FMMNTX021451 for ; Thu, 15 Jul 2010 19:22:23 -0300 Received: from [9.18.203.163] ([9.18.203.163]) by d24av05.br.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o6FMMMR2021445; Thu, 15 Jul 2010 19:22:22 -0300 Subject: Re: GDB hangs with simple multi-threaded program on linux From: Thiago Jung Bauermann To: Tom Tromey Cc: gdb@sourceware.org In-Reply-To: References: <1279208729.14577.21.camel@hactar> Content-Type: text/plain; charset="UTF-8" Date: Thu, 15 Jul 2010 22:22:00 -0000 Message-ID: <1279232541.14577.41.camel@hactar> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-07/txt/msg00050.txt.bz2 On Thu, 2010-07-15 at 12:44 -0600, Tom Tromey wrote: > >>>>> "Thiago" == Thiago Jung Bauermann writes: > > Thiago> I'm struggling with an issue which perhaps you already faced or > Thiago> thought about... > > I asked around about this, and it turns out that we have a patch in the > Fedora SRPM for it. Thanks for looking into it! > The approach in this patch seems to be racy. Roland says we can do > better if we enable exit tracing. I see this in linux-nat.c: > > /* Do not enable PTRACE_O_TRACEEXIT until GDB is more prepared to support > read-only process state. */ > > I wonder what that means :-) I will play with that option and see what happens... Thanks for sending the patch. It is racy but at least makes an effort to avoid the trap, which is an improvement. :-) > Thiago> 1. Is it true that when the main thread exits but there are other > Thiago> threads in the thread group, then no SIGCHLD is generated to notify GDB > Thiago> that it exited (perhaps because such a SIGCHLD could be ambiguous and > Thiago> mean that the whole process exited)? > > Yes, Roland said that no SIGCHLD is generated. Bummer. > Thiago> 2. Is there a way for GDB to wait on just the main thread instead of on > Thiago> the whole process when it waits on a TID which is also the PID? > > I guess not. Ouch. Looks like we have our hands tied here. :-/ > BTW, if you plan to work on this, it is also PR 10970. I do, and will update the PR accordingly. Thanks! -- []'s Thiago Jung Bauermann IBM Linux Technology Center