From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id FL9KJycS+mmR9xYAWB0awg (envelope-from ) for ; Tue, 05 May 2026 11:52:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1777996327; bh=NFWJXB3mJ6plpiKGirAJZY41LU5y3p4cmnqu8bknIGM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=bwJWFB9Anq4G4q+hziXf/z+Ws2aa0SeuLH2P0NPdUa9Ihk5s1t3GBXjVjtqIm8fLS h+VIfl2uyKh9mTChl2dVDv6vG2Yi0eVeeMLr5yVbzh0L5xbDpLCTDLt/qGKY/M19NS 8dgDDvrmqY91Wxw36yDJ6L+GUJfm3uvQzFiNEs84= Received: by simark.ca (Postfix, from userid 112) id 8990E1E067; Tue, 05 May 2026 11:52:07 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=uTudNhcK; dkim-atps=neutral Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (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 40D0A1E067 for ; Tue, 05 May 2026 11:52:06 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 77D064BA7992 for ; Tue, 5 May 2026 15:52:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 77D064BA7992 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=uTudNhcK Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id C32554BA7989 for ; Tue, 5 May 2026 15:51:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C32554BA7989 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C32554BA7989 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777996291; cv=none; b=KZKBPN+s3JjQQ8dWBfcndnH4VU0jG3ZhAPC3eKLcxgTBSjjlVDNtLecl3rot6IdrK6GpPVDtLizUsPN3RKYejQDEEgOwIDeflSL0IALqy/QmKiFvTOs1vD3aiali4JC5cOcj8R2JEFSy9uH5GQYGOnq20LavSOsf0h5p0LXDvjc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777996291; c=relaxed/simple; bh=NFWJXB3mJ6plpiKGirAJZY41LU5y3p4cmnqu8bknIGM=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=q+zPiCJVeJomFg6G70IHiOfEvcoC41HWrXMZTWQ8LKFrvrI+Nk/ShkzehLGYVzpEX7MFwqDFXZqUxoUuNcbKE36itBSWO0YqcxKedLnzWM37+OGewXaQXrSe+ItqhlAZ+CscQGOowZDR3H9D3cpEX2hrHq7GOfegB7HGbASLZQw= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C32554BA7989 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1777996290; bh=NFWJXB3mJ6plpiKGirAJZY41LU5y3p4cmnqu8bknIGM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=uTudNhcKqAS3NfR86lP7l/EAV6B0i7I9OGjzSbWMk+wVVoGzalLphV+YKbg5LLrO9 VlhIFiHnDRcgz4srXZRNz3GJ30Daos9S4cBjUeKx5rJhTgSQFZODUf4zpdH0RnDCnf 0hNbJfrCaiSYjpzwX7O39/fonOj5QG+PblfOj7cU= Received: by simark.ca (Postfix) id B08CA1E067; Tue, 05 May 2026 11:51:29 -0400 (EDT) Message-ID: <6ff2ff67-e93c-41b0-b55a-2ec6462e6061@simark.ca> Date: Tue, 5 May 2026 11:51:29 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb: fix an issue with thread list corruption To: "Metzger, Markus T" Cc: "gdb-patches@sourceware.org" References: <20260504071636.1571615-1-markus.t.metzger@intel.com> <20260504071636.1571615-2-markus.t.metzger@intel.com> Content-Language: en-US From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 2026-05-05 01:04, Metzger, Markus T wrote: > Hello Simon, > >> -----Original Message----- >> From: Simon Marchi >> Sent: Monday, May 4, 2026 5:30 PM >> To: Metzger, Markus T ; gdb- >> patches@sourceware.org >> Subject: Re: [PATCH] gdb: fix an issue with thread list corruption >> >> On 5/4/26 3:16 AM, Markus Metzger wrote: >>> When resuming a target in non-stop mode with 'c -a', the continue >> command >>> uses for_each_thread() to proceed each stopped thread individually. This >>> uses an all_threads_safe() iteration. >>> >>> If one of the stopped threads does an inline step-over, since the target >>> is non-stop, we stop_all_threads(), which involves update_thread_list(), >>> which, in turn, may delete_thread(). >>> >>> If this deleted the thread pointed to by the m_next safe iterator member, >>> the above all_threads_safe() iteration will be corrupted. >>> >>> The thread we're proceeding is stopped and there is no reason to delete >>> it. Consequently, there is no reason for all_threads_safe(), which isn't >>> that safe in this scenario. >>> >>> Iterate using all_threads() and inline proceed_thread_callback(). >> >> Just to try to make sure I understand the circumstances that lead the >> the failure correcty (and make sure this doesn't just cover up other >> problems): >> >> - thread 1 is stopped on a breakpoint >> - thread 2 is executing >> - displaced stepping is disabled >> - the target doesn't report thread events to the core >> - you "continue -a" >> - thread 1 starts an inline step-over, which calls stop_all_threads, >> which calls update_thread_list >> - meanwhile, thread 2 exits >> - update_thread_list causes thread 2 to be deleted >> - the safe iterator's m_next field now points to a deleted thread info Can you comment on whether the sequence of events above sounds correct? If it is, I think it would be possible to write a CPU test to reproduce it, that would be helpful along with the fix. Simon