From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41948 invoked by alias); 29 Jan 2018 16:25:57 -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 41938 invoked by uid 89); 29 Jan 2018 16:25:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=HContent-Transfer-Encoding:8bit X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 29 Jan 2018 16:25:55 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w0TGPmpB011359 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 29 Jan 2018 11:25:53 -0500 Received: by simark.ca (Postfix, from userid 112) id 9704A1E5B7; Mon, 29 Jan 2018 11:25:48 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 818A81E512; Mon, 29 Jan 2018 11:25:47 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 29 Jan 2018 16:25:00 -0000 From: Simon Marchi To: Pedro Alves Cc: Sergio Durigan Junior , gdb-patches@sourceware.org, Simon Marchi Subject: Re: [Regression] Segfault on native-extended-gdbserver + fork In-Reply-To: <669ec8c3-caa3-6901-b26c-00a7e20bc0d1@redhat.com> References: <20180119161628.21611-1-simon.marchi@polymtl.ca> <20180119161628.21611-3-simon.marchi@polymtl.ca> <87efmaebo3.fsf_-_@redhat.com> <931f8b594f7405649778f66ab2960a40@polymtl.ca> <669ec8c3-caa3-6901-b26c-00a7e20bc0d1@redhat.com> Message-ID: <1b82573ce66790c935eaff87b7565907@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.2 X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 29 Jan 2018 16:25:48 +0000 X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00600.txt.bz2 On 2018-01-29 11:00, Pedro Alves wrote: > On 01/28/2018 04:50 PM, Simon Marchi wrote: >> On 2018-01-28 01:32, Sergio Durigan Junior wrote: > >> I'm fine with this, but I was curious about what happens in Pedro's >> multi-target branch.  I remember he said that the detach_inferior(int) >> version disappears in that branch, though I can't find where he said >> that.  But looking at the branch I can see it's indeed the case: >> >>   >> https://github.com/palves/gdb/blob/palves/multi-target/gdb/inferior.c#L250 >> >> So I was wondering what remote_follow_fork calls in that case, since >> it can't call the detach_inferior(inferior *) version without an >> inferior.  Apparently it calls a new remote_detach_pid function: >> >>   >> https://github.com/palves/gdb/blob/palves/multi-target/gdb/remote.c#L5859 > > remote_detach_pid is not new. It exists in master. What that url > shows > is that I commented out the detach_inferior call in the branch. > > Because in this case, we'd detaching a remote process that the core > of gdb never learned about. Oops I read that wrong. >> >> This means (I just tried it) that it won't show the "[Inferior %d >> detached]\n" message in that case.  So what I would suggest is putting >> >>   if (print_inferior_events) >>     printf_unfiltered (_("[Inferior %d detached]\n"), pid); >> >> in its own function, called by both versions of detach_inferior for >> now (bonus, it de-duplicates the printing of the message).  In the >> multi-target branch, remote_target::follow_fork (renamed from >> remote_follow_fork) can call this function in the case where we don't >> have an inferior object. > > But why would we want to print that? We will have already printed > > "Detaching after fork from child process PID." > > from the common code. When native debugging, in this scenario, > we don't call detach_inferior either, right? Can't see why > we'd want to call it for remote. It's true that it's a bit of a lie to say "[Inferior PID detached]" if there never actually was an inferior for that PID. Since we never print "[Inferior PID detached]" on native in that case, I am fine with removing the call from remote.c. Sergio, that would fix the crash you found I think? Simon