From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id i7pmEDHtnmUp6jcAWB0awg (envelope-from ) for ; Wed, 10 Jan 2024 14:17:05 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=ITJ2Tu44; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 2ECBE1E0C2; Wed, 10 Jan 2024 14:17:05 -0500 (EST) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id E33CC1E098 for ; Wed, 10 Jan 2024 14:17:02 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 19C5838582AA for ; Wed, 10 Jan 2024 19:17:02 +0000 (GMT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 70F5038582B3 for ; Wed, 10 Jan 2024 19:16:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 70F5038582B3 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 70F5038582B3 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704914203; cv=none; b=sK+0+qgNlsjOWTnBgIqlBOv8bC4OiVqk1M0vKEfkuFO12TW1vJAFy6bpbzlpZQoEMkF4iB2rGxatpjuCWa/knAxiZMYi/tFLJA2BN3LGAZbTb2T9xkfepGY5gJTOEyZ/nTKY7bLrpwdSw2RmihGimTCaXEmnAFKmJgcEDenrpJA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704914203; c=relaxed/simple; bh=oWedqFYNse8urU/dAxlb8JL2Yk0HHhDatRjypbrUS8I=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=KThu8r1gIIFKLFi+9dwTfUlmqtppRL+awdXihBMWj5h9j/bJxN9bj9ViJ1acEneaqVK0DLn0cVIpkSGjofl0S+dyALSHZpv2VummKls/ewtxVJsD8GvJcDrmzsUeJ1Ylgh6NQ8QSLJBW+KOMVJOuh1f/Tfn/CLO8RzP2I5o8GG4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1704914201; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6ocThTB7IadxIwgUix4RkvI3UkcAcNve1wN6k+tJIVU=; b=ITJ2Tu44+nUjD5ZzyFtnMBkO9eMQcta1p5QXPw9eADzXjWv/1JR+LvZel0gFlo3hwrEgq/ EVsZhMUmBrR9Zrha9XkDCF9xWs10UIegA+5ukAjErLE2xD70iGvoDMF9g6/kWFMYrGLR01 NSN/1FMD6mjBH/sOwgIvMcpWLcZ4PRk= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-661-rDeq1m1iNzWh3NQUXTPn3w-1; Wed, 10 Jan 2024 14:16:39 -0500 X-MC-Unique: rDeq1m1iNzWh3NQUXTPn3w-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 18814185A780; Wed, 10 Jan 2024 19:16:39 +0000 (UTC) Received: from f39-zbm-amd (unknown [10.22.32.106]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9C0ABC15E6A; Wed, 10 Jan 2024 19:16:38 +0000 (UTC) Date: Wed, 10 Jan 2024 12:16:36 -0700 From: Kevin Buettner To: Tom de Vries Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] [gdb/testsuite] Extend gdb.base/kill-during-detach.exp Message-ID: <20240110121636.359dfbf6@f39-zbm-amd> In-Reply-To: <20240109165620.18066-1-tdevries@suse.de> References: <20240109165620.18066-1-tdevries@suse.de> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org On Tue, 9 Jan 2024 17:56:20 +0100 Tom de Vries wrote: > I ran into the following FAIL: > ... > (gdb) python kill_and_detach()^M > Traceback (most recent call last):^M > File "", line 1, in ^M > File "", line 7, in kill_and_detach^M > gdb.error: Selected thread is running.^M > Error while executing Python code.^M > (gdb) FAIL: gdb.base/kill-during-detach.exp: exit_p=true: checkpoint_p=true: \ > python kill_and_detach() > ... > > The FAIL happens as follows: > - gdb is debugging a process A > - a checkpoint is created, in other words, fork is called in the inferior, > after which we have: > - checkpoint 0 (the fork parent, process A), and > - checkpoint 1 (the fork child, process B). > - during checkpoint creation, lseek is called in the inferior (process A) for > all file descriptors, and it returns != -1 for at least one file descriptor. > - the process A continues in the background > - gdb detaches, from process A > - gdb switches to process B, in other words, it restarts checkpoint 1 > - while restarting checkpoint 1, gdb tries to call lseek in the inferior > (process B), but this fails because gdb incorrectly thinks that inferior B > is running. > > This happens because linux_nat_switch_fork patches the pid of process B into > the current inferior and current thread which where originally representing > process A. So, because process A was running in the background, the > thread_info fields executing and resumed are set accordingly, but they are not > correct for process B. > > There's a line in fork_load_infrun_state that fixes up the thread_info field > stop_pc, so fix this by adding similar fixups for the executing and resumed > fields alongside. > > The FAIL did not always reproduce, so extend the test-case to reliably > trigger this scenario. Thanks for the detailed explanation! Makes sense to me... Approved-By: Kevin Buettner