From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116842 invoked by alias); 29 Jan 2018 17:47:39 -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 116832 invoked by uid 89); 29 Jan 2018 17:47:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy= X-HELO: mail-wr0-f172.google.com Received: from mail-wr0-f172.google.com (HELO mail-wr0-f172.google.com) (209.85.128.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 29 Jan 2018 17:47:37 +0000 Received: by mail-wr0-f172.google.com with SMTP id 41so6772714wrc.9 for ; Mon, 29 Jan 2018 09:47:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Iim1Ip8IBhfS8x6fiX8aUf2eQxasFcluFkivMA4ceek=; b=S4bD2ueqPWw/qkkB9XEp8qbPjD5ioiLoJlmAiT7ca52en2xj6KVwUmIumlsGnAem4p l++MWDZe/yPhW10/84KgheKw0A6hA8npbCUr69I/vUw5edSpbQK806320Moi18VL7IUS 0LuSr8idJIHkqTPBowKO2el3UX7AniY5FHx4Ghq4WGlaG7e1kxOmOsPDJg+JUH1ZJhhw 4CNIDyi0Fzy4/m5U08Uery624tw2mAgeewvTdNw9xGWvqoLKTv+1IAt/R+N0ZH/ATjNl 78Ss6vjk0nA0JwP7RjBMyA5cI6sTD0zD8nqPjamm+dtaP2/p5m5YxvAe5sW/rSpu90Pj BUOQ== X-Gm-Message-State: AKwxytcivL+vuoH5f7OoaW/3s1iXOvGpd1Qc+PZJ/LxLmyxMO72jbXqL Bjb39b5fy56QgjeXzt9UjKf96Q== X-Google-Smtp-Source: AH8x227KWvddhva4oXaL3sBw0dUrDLILklTK7+n8G3r3ib862F0onz2lJPbccwG2elPtvQ1stIb/mw== X-Received: by 10.223.128.169 with SMTP id 38mr19304945wrl.104.1517248055663; Mon, 29 Jan 2018 09:47:35 -0800 (PST) Received: from ?IPv6:2001:8a0:f915:7500:56ee:75ff:fe8d:232b? ([2001:8a0:f915:7500:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id u194sm9778813wmd.8.2018.01.29.09.47.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jan 2018 09:47:34 -0800 (PST) Subject: Re: [Regression] Segfault on native-extended-gdbserver + fork To: Sergio Durigan Junior , Simon Marchi 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> <87372o8t45.fsf@redhat.com> Cc: gdb-patches@sourceware.org, Simon Marchi From: Pedro Alves Message-ID: Date: Mon, 29 Jan 2018 17:47:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <87372o8t45.fsf@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-01/txt/msg00611.txt.bz2 On 01/29/2018 05:36 PM, Sergio Durigan Junior wrote: > From 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; > } > Please also mention gdb.base/foll-fork.exp. > 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 extended-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 = 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 == NULL'. s/there is not/there is no/ > > 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. Add something like this here: Before bc09b0c1, that call was already a nop (exit_inferior_1 bails out early if you pass it a NULL inferior), except that it printed "Inferior PID detached" when "set print inferior-events" is on. Since native debugging doesn't call detach_inferior in this case, removing the call from remote aligns remote debugging output with native debugging output further. and it's good to me. Thanks, Pedro Alves