From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 1j8POZ+7+GnI+xIAWB0awg (envelope-from ) for ; Mon, 04 May 2026 11:30:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1777908639; bh=JnsfsCylXRbql4SECPG1KDxciXZQcq7OWAOo3LGRtGQ=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=VwxZHkEdpq5G5OUmYB5RMI6Ablq6clpTRIf/Kf6J3KjHjtN6kKqgjHDsNG/A+9TW1 EJ9vDN3TxJWc17BLAcXocTs3Va7D4PFtDueLwHnTePIXtlYRMOJ05oqDN19WRPvkcj 6eQP0lgMCYkUTcLCljFpPbc1PCI5/xE9Q5z4jxMI= Received: by simark.ca (Postfix, from userid 112) id D7CA91E067; Mon, 04 May 2026 11:30:39 -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=NISXvRdk; 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 020D11E067 for ; Mon, 04 May 2026 11:30:39 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 8F4544BAD15D for ; Mon, 4 May 2026 15:30:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8F4544BAD15D 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=NISXvRdk Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id AE1924BA79A2 for ; Mon, 4 May 2026 15:30:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AE1924BA79A2 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 AE1924BA79A2 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=1777908614; cv=none; b=RAU8FKAiM3kFgsBNGZcLsnTUJHopWHoK1ClELJn6YuMOU335g51+RI/bk8midHvr2jbTZnUIL+PYyGR9jPrSvStZI8lD5u+3hYY6lbOGkqUpSs+CbV/eYRHZ9oX5HhbDg2YrGg3ax174JZz5o3bScy61oo3j4bK5kP56eh/f35M= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777908614; c=relaxed/simple; bh=JnsfsCylXRbql4SECPG1KDxciXZQcq7OWAOo3LGRtGQ=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=qzFvjg7CJMsIvUXNoH7bGD6ZtZNthhBcUYadTmPxehyw2+5i6rW6HLn4gxl4fRWhE8pJc9XJUan4g/jAhlaMzeq7q484Y/aa/+Bs7aNIX8lPBOnUecvcYOrVFjy6DtPy4yH+xy7BzWg83ET2HzfJYU32+d/kwggrOZmlrXb0Pio= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AE1924BA79A2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1777908614; bh=JnsfsCylXRbql4SECPG1KDxciXZQcq7OWAOo3LGRtGQ=; h=Date:Subject:To:References:From:In-Reply-To:From; b=NISXvRdk8F1kdDnwH2lBRH9NTMrb+H9FPASW1dhEG1lWmtNq3kMVJWHb9TO674RAC qa0S4sDFYV32+t34nxr17ED4eZQwefEgGAsyCU1+hZ7hUcJNEOhHTNMQYcEHt7RLuu iy9bYZXr0rs3solZy92/6QldH8zO097CgAbjl2xQ= Received: by simark.ca (Postfix) id 033D01E067; Mon, 04 May 2026 11:30:14 -0400 (EDT) Message-ID: Date: Mon, 4 May 2026 11:30:13 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb: fix an issue with thread list corruption To: Markus Metzger , gdb-patches@sourceware.org References: <20260504071636.1571615-1-markus.t.metzger@intel.com> <20260504071636.1571615-2-markus.t.metzger@intel.com> Content-Language: fr From: Simon Marchi In-Reply-To: <20260504071636.1571615-2-markus.t.metzger@intel.com> 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 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 I thought: don't we now ask the target to report thread exit events when doing steps now (to handle step over exit)? But we only ask for to report the exit event for the stepping thread, so the target wouldn't report the exit of thread 2. If my understand above is corerct, then I agree with your reasoning. The currently iterated on thread is stopped and should not disappear, except maybe on a misbehaving target (in which case we'd fix the target). Maybe it could happen with a remote target where communication breaks during this update_thread_list, but that is notoriously difficult to handle correctly. > @@ -762,7 +739,30 @@ continue_1 (int all_threads) > scoped_disable_commit_resumed disable_commit_resumed > ("continue all threads in non-stop"); > > - for_each_thread (proceed_thread_callback); > + /* Do not use all_threads_safe in case threads get removed while > + resuming THREAD. */ I understand this comment because I just read your commit message, but I don't think I would understand it in isolation. Because all_threads_safe is usually used to handle cases where threads (the current one) get removed while iterating. I suggest: /* Do not use all_threads_safe, because it's possible for the next thread to get removed while resuming THREAD. We know that thread is stopped and should not disappear under our feet. */ Then if I wanted to understand more about the circumstances where this check was added, I would do a git blame and find the commit message. Simon