From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id obx/KOCr/Gmfdx8AWB0awg (envelope-from ) for ; Thu, 07 May 2026 11:12:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1778166752; bh=t8zDk2gGBfJoBVT9GV0UkDANrneBrU7LSOwL6kyTuUE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=bd7SM88AYn1Vb5oGR0N+BEWw0f80Mw48RM/1Xpi/vU/wMxVURpBNnEbEot0cZPBhL MXuKiwrqoEAVqodF6Gk8uLwFIwWfZUpNP/c7Iy3ohy06wfu3Ub4B+zWhe12AuN7RWN iM+CadAwDiVlu2uGXzPSilih4E8DkDb4aw/F+Xks= Received: by simark.ca (Postfix, from userid 112) id A08E11E0BA; Thu, 07 May 2026 11:12:32 -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=tCJB0A4M; 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 DA9B21E067 for ; Thu, 07 May 2026 11:12:31 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7FD894BA2E0E for ; Thu, 7 May 2026 15:12:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7FD894BA2E0E 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=tCJB0A4M Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 64ECE4BA2E24 for ; Thu, 7 May 2026 15:11:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 64ECE4BA2E24 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 64ECE4BA2E24 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=1778166697; cv=none; b=ozuj1DSF7z1qOX9NTo1Y7K6yhIuS4APYB+prmIlsDOe9YtqhDHqBIBm2U9uvFGgJAbwUg8wMc6deUgGrIREjCfAMU+s/4/j7Y7ado8rl6bCAatytP6IuxpSLHq2YVfMLwbiq1I/j2eHlIRaW1Z6TJik+QDBmpoyxf3Wrxryz0Tw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778166697; c=relaxed/simple; bh=t8zDk2gGBfJoBVT9GV0UkDANrneBrU7LSOwL6kyTuUE=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=df+Ap0M+yef8S4lam7OuQfbsSJ8CiJapHXAgV0oCLbJplMrGonWzt6ftZY4JiqCeWqf0A8FFPMDbGXZxwmP+EaX6tJBuytkSfm7Yh9vjMo9XLx313h4st+KDpiGqkExo9DFB1e1e2/JyIWGO9QC5lY20mSb34xf8IVPnU6jWZlc= 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=tCJB0A4M DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 64ECE4BA2E24 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1778166695; bh=t8zDk2gGBfJoBVT9GV0UkDANrneBrU7LSOwL6kyTuUE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=tCJB0A4M4Rn4qhDpg6mgkJ/ic1n3taOXiUhpO8FL7k9/wpI0mzdHPYvBIoRqQGs1t BcvrfQ/nZ9UmSw9Kfhhldre7Y+IpRn5SxirYg9qIj05TxDE95DRQ5ash/31a0eg2RP LN9O21qCJRgpxWxnNdZnflIKJL1PG4ev3ce4GJ1I= Received: by simark.ca (Postfix) id 9EF271E067; Thu, 07 May 2026 11:11:34 -0400 (EDT) Message-ID: <5b5e0342-ff7e-44f4-803b-aa96075229af@simark.ca> Date: Thu, 7 May 2026 11:11:34 -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> <81a1a827-5c22-4f24-852a-1c85d09c30cc@simark.ca> Content-Language: fr 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 5/7/26 3:36 AM, Metzger, Markus T wrote: > And what happens without ASan? Do we introduce yet another sporadically failing test? Perhaps, but such is the nature of "use after free" bugs, and that's the point of ASan, to make them fail predictably. Some people (including me) test with ASan enabled, so someone would certainly catch it. In 2026 we can assume that ASan is a core component of testing the software. If a test is failing sporadically because of a real bug in GDB, then the test is doing its job. If a test fails sporadically but not because of a real bug in GDB, then it's a bad test. > If we only created two additional threads, we could vary which thread we're stepping > in two different runs of the test program, which makes the test program fairly trivial. > > We'd need to step from one pthread_create() to the next to guarantee the order in > which GDB adds the threads. As long as GDB adds them to either the front or the > back of the thread list consistently, we would get the same order in the two runs, > and by varying the thread we're stepping, we would cover both possible orders. Not sure I understand, but if you have an idea to improve what I propose, go for it. > But we wouldn't be able to guarantee that the other thread exited at just the right > moment, would we? We try to mitigate that by repeating this 100 times, but this is > just asking for the test to fail sporadically at a random iteration - or pass. Like I explained in my previous message, I think that with the test I propose, the thread doesn't have to exit in a very tiny window for the test to catch the failure. That's because when threads exit on the remote target, GDB doesn't learn about it until the next thread list update. So the thread has to exit after GDB learned about the thread (which is at the previous breakpoint hit I think), and before the next "continue -a". It's a big window, so it's almost guaranteed that it will happen, since the thread is short-lived. In my testing, it always caught it at iteration 1. I think that the crash could be observed with the linux-nat target, but then the window would be much smaller. With the linux-nat target, the thread_info is deleted as soon as the thread exits (and linux-nat processes the event). So for the crash to be observed, the thread would have to exit between the moment the safe iterator grabs a reference to the thread_info and the moment it tries to use it, that is a small window. > We have too many such tests already. They may indicate an actual problem, or maybe > the test itself is broken or inherently non-deterministic. What such tests definitely do is > create noise when trying to test a completely unrelated patch, thus slowing down GDB > development. With your fix, the test shouldn't randomly fail. If it does, then it means there is a problem with the test or with GDB, which should be fixed either way. The solution to this is not to not have tests. > To get this deterministic, one would need to mock the remote target to guarantee > the ordering of thread exit and step completion events. Something like gdbreplay, > but with hand-written logs, which would need to be maintained whenever anything > in the remote communication changes. For more substantial changes to the remote > communication, this could become a significant burden. If you wanted to write a test using gdbreplay, I wouldn't be against it, but I also think that the maintenance burden probably makes it not worth it. I think that gdbreplay is useful to mock a misbehaving remote, for example. I think that "live" debugging test still has value, because it tests against a real system. For example, perhaps that running this new test on Windows will point out that something is broken in the Windows target or the Windows gdbserver, who knows. > And without additional tooling, like ASan, we still wouldn't be able to fail deterministically. So we shouldn't ever write tests for use-after-free or buffer overflow bugs? Simon