From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104878 invoked by alias); 29 Jan 2018 17:36:31 -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 104869 invoked by uid 89); 29 Jan 2018 17:36:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 29 Jan 2018 17:36:29 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 24B1487630; Mon, 29 Jan 2018 17:36:28 +0000 (UTC) Received: from localhost (unused-10-15-17-193.yyz.redhat.com [10.15.17.193]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8BE3E5C266; Mon, 29 Jan 2018 17:36:27 +0000 (UTC) From: Sergio Durigan Junior To: Simon Marchi Cc: Pedro Alves , gdb-patches@sourceware.org, Simon Marchi Subject: Re: [Regression] Segfault on native-extended-gdbserver + fork 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> <1b82573ce66790c935eaff87b7565907@polymtl.ca> <87mv0w8tnr.fsf@redhat.com> Date: Mon, 29 Jan 2018 17:36:00 -0000 Message-ID: <87372o8t45.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00609.txt.bz2 On Monday, January 29 2018, I wrote: > On Monday, January 29 2018, Simon Marchi wrote: > >> 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: >>>> This means (I just tried it) that it won't show the "[Inferior %d >>>> detached]\n" message in that case.=C2=A0 So what I would suggest is >>>> putting >>>> >>>> =C2=A0 if (print_inferior_events) >>>> =C2=A0=C2=A0=C2=A0 printf_unfiltered (_("[Inferior %d detached]\n"), p= id); >>>> >>>> in its own function, called by both versions of detach_inferior for >>>> now (bonus, it de-duplicates the printing of the message).=C2=A0 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? > > I was also unsure about printing the message in this case, because > there's no real detach happening. I'm fine with not printing it. And > yes, removing the call to "detach_inferior" also fixes the problem. > > I'll prepare a patch. Here's what I have. WDYT? I'll address Pedro's comment about changing the "[Inferior PID detached]" output in another patch. --=20 Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ =46rom 4a37d08ca6c1aec7f47e2278b0fe78a0038eb9ee Mon Sep 17 00:00:00 2001 From: Sergio Durigan Junior Date: Mon, 29 Jan 2018 12:29:21 -0500 Subject: [PATCH] Don't call "detach_inferior" on "remote_follow_fork" This patch fixes a regression that has been introduced by: commit bc09b0c14fb713a9aec25e09b78499f3bc2441b5 Date: Fri Jan 19 11:48:11 2018 -0500 Make linux_nat_detach/thread_db_detach use the inferior parameter Consider the following example program: #include int main (int argc, char *argv[]) { fork (); return 0; } When running it under gdbserver: # ./gdb/gdbserver/gdbserver --multi --once :2345 And debugging it under GDB, we see a segmentation fault: # ./gdb/gdb -q -batch -ex 'set remote exec-file ./a.out' -ex 'tar extende= d-remote :2345' -ex r ./a.out Starting program: ... [Detaching after fork from child process 16102.] Segmentation fault (core dumped) The problem happens on inferior.c:detach_inferior: void detach_inferior (inferior *inf) { /* Save the pid, since exit_inferior_1 will reset it. */ int pid =3D inf->pid; ^^^^^^^^^ exit_inferior_1 (inf, 0); if (print_inferior_events) printf_unfiltered (_("[Inferior %d detached]\n"), pid); } When this code is called from remote.c:remote_follow_fork, the PID is valid but there is not 'inferior' associated with it, which means that 'inf =3D=3D NULL'. The proper fix here is to not call "detach_inferior" when doing remote follow-fork, because we don't have an inferior to detach on the host side. This has been regtested using BuildBot and no regressions were found. gdb/ChangeLog: 2018-01-29 Sergio Durigan Junior * remote.c (remote_follow_fork): Don't call "detach_inferior". --- gdb/remote.c | 1 - 1 file changed, 1 deletion(-) diff --git a/gdb/remote.c b/gdb/remote.c index 5ac84df0a0..74d18f7b17 100644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -5206,7 +5206,6 @@ remote_follow_fork (struct target_ops *ops, int follo= w_child, child_pid =3D ptid_get_pid (child_ptid); =20 remote_detach_pid (child_pid); - detach_inferior (child_pid); } } return 0; --=20 2.14.3