From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id JUBVFDuK+2moNBsAWB0awg (envelope-from ) for ; Wed, 06 May 2026 14:36:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1778092603; bh=Rop1ZA24gS+x/tcUGLsl5/vsD67qMvCMGnQguvvEz1I=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=cAZsSoxzjbu4Sj3Ww7OpjUxsEQw2XmBz1hscVel26wjopypkZkGD47Z4K8h57MceI Dyh2+PvY7AicWaUc0kVrC7TD1zthVSr5EQlT6KNeM/xqfTOXJ+20Y7iL5ctelr45qw B8vZrav6wC1nM9Re2c71+HicQGV1sqIuGcgWx6gQ= Received: by simark.ca (Postfix, from userid 112) id 404E31E0BA; Wed, 06 May 2026 14:36:43 -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=rZnIkfMj; 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 81D301E067 for ; Wed, 06 May 2026 14:36:42 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D67E34BA23DE for ; Wed, 6 May 2026 18:36:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D67E34BA23DE 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=rZnIkfMj Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id C1A0A4BA2E12 for ; Wed, 6 May 2026 18:36:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C1A0A4BA2E12 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 C1A0A4BA2E12 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778092573; cv=none; b=UH5nOYwNufOyesdWVnv/iB7veXNEN/3lZm6VKMILJoqT9CrbE8Ccu11f9R2cis0u5kK1psqsQ8zgdZzXJhUyueHo12rQ6lX9aa3nK6PgzOhNkCovpL3xKJNMGAC4b5GN9GkP5SvPXy1e7kVl0G+wfqEyKP8oFpfhK6TPGR2dYtI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778092573; c=relaxed/simple; bh=Rop1ZA24gS+x/tcUGLsl5/vsD67qMvCMGnQguvvEz1I=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=DUZm+L8qUcseIFZOJtx+Dqm+fKa26mk+056q14LqqWXRHdHj0NzJJ0zG7koeVatsJf5xrL25QyM6UO1I60846jHL2VYGgJLQ63xic2frDbS+QclPIkwb8gahGhD2otmaJpiUCkt2d2DsRFyWWdctpY6AShGOkJ8IlQotOdk05tQ= ARC-Authentication-Results: i=1; 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=rZnIkfMj DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C1A0A4BA2E12 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1778092571; bh=Rop1ZA24gS+x/tcUGLsl5/vsD67qMvCMGnQguvvEz1I=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=rZnIkfMj0FmTBHq62/EFA/dSBZ+XMBUVYdmVRFpXx28yXAkXrSD8W6vaRCqfgY2e3 rQnul/2ber1edUcP/Fw4SO+0sH5QGzr645vZN/ufyqIcl6aCkR7i3OSh/JVPlMfXWt EryjfQBzGYaxTBvGm46ChTeqNkfKLWGYzry9YuPQ= Received: by simark.ca (Postfix) id CF7A21E067; Wed, 06 May 2026 14:36:10 -0400 (EDT) Message-ID: <81a1a827-5c22-4f24-852a-1c85d09c30cc@simark.ca> Date: Wed, 6 May 2026 14:36:10 -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> <6ff2ff67-e93c-41b0-b55a-2ec6462e6061@simark.ca> 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-06 01:43, Metzger, Markus T wrote: > Hello Simon, > >>>> 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. > > The sequence sounds good, but I wonder how we would ensure that thread 2 > exits just when we need it to. Usually, by hammering. But I think it's not as difficult as it sounds. The state before the "continue -a" on thread N is that GDB knows about thread N+1. Assuming that thread N+1 is a short-lived thread (one that does nothing but exit), it exits even before the "continue -a" is issued, but GDB doesn't know that until the next thread list update. When you "continue -a", GDB iterates using all_threads_safe, without doing any thread list update. When iteration reaches thread N, the next thread is N+1, exited on the target but it still exists in GDB's mind. Thread N starts its inline step-over, and etc etc until the crash. > This is non-stop mode, so we should learn about the exit immediately. > The test would also need to rely on the ordering of threads in the > thread list. And detecting the issue requires the next pointer of the > next element to be overwritten in a way that causes a deterministic > effect - like crashing GDB. We wouldn't want to add another test that > fails sporadically. I wrote a test that fails consistently (at least with ASan) with the board native-extended-gdbserver: https://review.lttng.org/c/binutils-gdb/+/17704 (gdb) PASS: gdb.threads/continue-a-step-over-other-thread-exit.exp: step_over_thread_slot=1: continue to break_here continue -a Continuing. ================================================================= ==1250831==ERROR: AddressSanitizer: heap-use-after-free on address 0x7d0984eb4480 at pc 0x564f8b3da4dd bp 0x7ffdad6a63d0 sp 0x7ffdad6a63c0 With your fixes, it passes. Feel free to check it out and add it to your patch. It will need a bit of cleanup, and there is a FIXME saying that it won't work with native-gdbserver because it requires inferior args. I have another patch series that I need to send that add the ability to pass inferior args when using native-gdbserver, I'll try to get that done. Simon