From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43185 invoked by alias); 11 Apr 2017 23:51:17 -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 43081 invoked by uid 89); 11 Apr 2017 23:51:16 -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,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=holding 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; Tue, 11 Apr 2017 23:51:15 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 238577F7A5 for ; Tue, 11 Apr 2017 23:51:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 238577F7A5 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=palves@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 238577F7A5 Received: from cascais.lan (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id AE68F17C3C for ; Tue, 11 Apr 2017 23:51:15 +0000 (UTC) From: Pedro Alves To: gdb-patches@sourceware.org Subject: [PATCH 2/8] Fix follow-fork latent bug Date: Tue, 11 Apr 2017 23:51:00 -0000 Message-Id: <1491954673-29172-3-git-send-email-palves@redhat.com> In-Reply-To: <1491954673-29172-1-git-send-email-palves@redhat.com> References: <1491954673-29172-1-git-send-email-palves@redhat.com> X-SW-Source: 2017-04/txt/msg00299.txt.bz2 A later patch in the series adds an assertion to switch_to_thread that the resulting inferior_ptid always matches the "current_inferior()" inferior. This exposed a latent bug in the follow-fork code, where we're building the fork child inferior. We're switching inferior_ptid, but not the current inferior object... gdb/ChangeLog: yyyy-mm-dd Pedro Alves * infrun.c (follow_fork_inferior): Also switch the current inferior. --- gdb/infrun.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/gdb/infrun.c b/gdb/infrun.c index b5eb4ab..c7298a3 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -498,11 +498,11 @@ holding the child stopped. Try \"set detach-on-fork\" or \ child_inf->gdbarch = parent_inf->gdbarch; copy_inferior_target_desc_info (child_inf, parent_inf); - old_chain = save_inferior_ptid (); - save_current_program_space (); + old_chain = save_current_space_and_thread (); inferior_ptid = child_ptid; add_thread (inferior_ptid); + set_current_inferior (child_inf); child_inf->symfile_flags = SYMFILE_NO_READ; /* If this is a vfork child, then the address-space is @@ -631,6 +631,7 @@ holding the child stopped. Try \"set detach-on-fork\" or \ inferior_ptid = child_ptid; add_thread (inferior_ptid); + set_current_inferior (child_inf); /* If this is a vfork child, then the address-space is shared with the parent. If we detached from the parent, then we can -- 2.5.5