From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94415 invoked by alias); 24 Jun 2016 22:36:22 -0000 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 Received: (qmail 94394 invoked by uid 89); 24 Jun 2016 22:36:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=our, wish X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 24 Jun 2016 22:36:20 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 42BFE116C6B; Fri, 24 Jun 2016 18:36:18 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PtRemRt6eqG2; Fri, 24 Jun 2016 18:36:18 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 0FE92116C6A; Fri, 24 Jun 2016 18:36:17 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 7C05C428F4; Fri, 24 Jun 2016 15:36:16 -0700 (PDT) Date: Fri, 24 Jun 2016 22:36:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: RFA/gdbserver: GDB internal-error debugging threaded program with breakpoint and forks Message-ID: <20160624223616.GE3295@adacore.com> References: <20160512171650.GC26324@adacore.com> <5734C06C.8040008@codesourcery.com> <20160623225935.GC3295@adacore.com> <20160624181152.GD3295@adacore.com> <31daa4d2-359d-db9a-e9c8-d7bfbb327570@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31daa4d2-359d-db9a-e9c8-d7bfbb327570@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2016-06/txt/msg00413.txt.bz2 > I haven't gone through this with fine-tooth comb yet, but, > will we still have the same problem if _two_ threads (or inferiors...) > fork at the "same" time, and we end up reporting one fork, while > leaving the another one pending? At the moment, I do not think so, because we seem to just process the fork even without requesting an update of the thread list. This is an extract of the remote protocol transmissions that show us resume the execution of our program (vCont;c), receive the fork event (T05fork), do a bunch of stuff to handle the fork event (and in particular "D"etaching from the child process), followed by the resumption of our program's execution (vCont;c): Sending packet: $vCont;c:p2992.-1#b4... Packet received: T05fork:p299c.299c;01:bffff5e0;40:0fe87158;thread:p2992.2992;core:1; Sending packet: $Hgp299c.299c#5b...Packet received: OK Sending packet: $z0,1000224c,4#f2...Packet received: OK Sending packet: $z0,10003218,4#c5...Packet received: OK Sending packet: $z0,1000336c,4#f6...Packet received: OK Sending packet: $D;299c#86...Packet received: OK Sending packet: $vCont;c:p2992.-1#b4...Packet received: T05swbreak:;01:482009e0;40:10003218;thread:p2992.299a;core:0; I wish I could give you a stronger justification, but at least we seem to be OK, so the patch could give us a fix while we think a more solid approach through. -- Joel