From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57880 invoked by alias); 29 Jan 2018 16:01:06 -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 57868 invoked by uid 89); 29 Jan 2018 16:01:05 -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-wm0-f54.google.com Received: from mail-wm0-f54.google.com (HELO mail-wm0-f54.google.com) (74.125.82.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 29 Jan 2018 16:00:54 +0000 Received: by mail-wm0-f54.google.com with SMTP id 143so15252411wma.5 for ; Mon, 29 Jan 2018 08:00:54 -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=y6TMMQ8SB6zlvjbw/PIzO4SgTBWphRsPSOUirGFeB9s=; b=bJ5yk0HTPiH5THqqt9oDilJMqS/7gcwCkPUmxJcInSEdKZJkGOWUq1a3H9fqXAqbX0 aXOQILPk49te9GZKRoqopnAHLKHygR2gQApkpc6RhsOx6AKNxcxL6Z1+CKZrCZq1dtwL 2kBRM64+fN2cZWnXKCftWqJ9NYl8ohUExvvxcKkG4B2tZnVvoDPYNAmcL89jf790h95S fD/ETIEw9T3t3tGSjJR2CU1VtndntRCZYWTx6HcQW9+VXkInCFvFWJTF3zFVEt2dUGQ9 8ng/+6ZIyn+rneiB4r8GAxs90Y0DyFTPzmzhN6tB3MZjl9MSxpSU8idPaYF2bdXWMy6Q Zogw== X-Gm-Message-State: AKwxyteQjFenf6LPyM4qGD8MtPlYS6LHBgADUJ6oZgYeq7ErVN2RQjvd mpJOvKPR/z3Oq36vvmnVPROD9Q== X-Google-Smtp-Source: AH8x225pkPGS2bXwh6A6qzUqS+u5lOxbJjBvIrkUF9Z+6ynmIW4RvkyJktevxjYEQ1kca7DNg49sXA== X-Received: by 10.28.84.87 with SMTP id p23mr19148854wmi.92.1517241652463; Mon, 29 Jan 2018 08:00:52 -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 f19sm10771722wmf.23.2018.01.29.08.00.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jan 2018 08:00:51 -0800 (PST) Subject: Re: [Regression] Segfault on native-extended-gdbserver + fork To: Simon Marchi , Sergio Durigan Junior References: <20180119161628.21611-1-simon.marchi@polymtl.ca> <20180119161628.21611-3-simon.marchi@polymtl.ca> <87efmaebo3.fsf_-_@redhat.com> <931f8b594f7405649778f66ab2960a40@polymtl.ca> Cc: gdb-patches@sourceware.org, Simon Marchi From: Pedro Alves Message-ID: <669ec8c3-caa3-6901-b26c-00a7e20bc0d1@redhat.com> Date: Mon, 29 Jan 2018 16:01: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: <931f8b594f7405649778f66ab2960a40@polymtl.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-01/txt/msg00598.txt.bz2 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. > > 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. I think we should just remove that detach_inferior call, like in the multi-target branch. Thanks, Pedro Alves