From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id dMF1H4oYMmqqVgsAWB0awg (envelope-from ) for ; Tue, 16 Jun 2026 23:46:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1781667978; bh=A35xef5LyWgOuepzeZGwOvI08AuwA7dFpauFmkqnlLs=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=sxZoGYCbG4PVYN6PfNtU2KgM5IlmsMmpghSvZt3dQF84Q/KPSwLZDAFw7yW/8+LvS I+cVSTXF7nQ1IXF8w4C4DJR/ZY/uJfR9UVcMPtb8hsySJ0ISiiyB4dZoeC6rDYmK1P 76sFy4ZCZE1RpBEQK7Td9JbLiC6smk4/zZJk/+fY= Received: by simark.ca (Postfix, from userid 112) id 704171E024; Tue, 16 Jun 2026 23:46:18 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.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 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=b7fTXS55; 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 BAC581E024 for ; Tue, 16 Jun 2026 23:46:16 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 55085490265C for ; Wed, 17 Jun 2026 03:46:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 55085490265C 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=b7fTXS55 Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id F36EC4902640 for ; Wed, 17 Jun 2026 03:44:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F36EC4902640 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 F36EC4902640 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=1781667862; cv=none; b=CgR1BqonI6ql9OPqC3F9GY2t9d9B8EWC0wE89d+1dDR4sqpFdubMGbT5J8qc7kYhKDyDB2i+7V9tkYCcdz6o0ayJ+TD2XOQ1T7f/8WqKzk/Xk7pQ+fXH/uK2RQSD+cTEpnHZTxIFmiCW0Q1D0mDZXv4UdlxvfbyvisgNYV2E0yQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1781667862; c=relaxed/simple; bh=A35xef5LyWgOuepzeZGwOvI08AuwA7dFpauFmkqnlLs=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=BkH2m+0gZcKYC+jp3PYmTGcZIFvVpvqhggxyQcwdEooVDXqC6H99+UWd+TtQZi2AELVmU/X8RvNs703yumaa50ZPSx8YUDlo4TqxsZbI30nAxCj8Ii3bA+v0OWKxx9sUrVH82aK36eU5O9BcIfUpp8JqU/oEfk6l329OWXCD6iY= 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=b7fTXS55 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F36EC4902640 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1781667860; bh=A35xef5LyWgOuepzeZGwOvI08AuwA7dFpauFmkqnlLs=; h=Date:Subject:To:References:From:In-Reply-To:From; b=b7fTXS55utSYM4n0BIWW0I8ieqnUSU3u5WraVvJ9IvjNQGd8jnRqRfO92i2QaUsQb qXnOa/qb49c1m5i7T+PHZC1iF1kwQsVUjq4KGvIRmGcfFaa+zx5sGMv2MEnY0ynqfV z419PiSDogC0/Wk7Q2bgVwlWNdPGsQXcLp6VuGGI= Received: by simark.ca (Postfix) id BD15B1E024; Tue, 16 Jun 2026 23:44:20 -0400 (EDT) Message-ID: <15e03eb6-40b4-4f69-a96b-57e3650e021f@simark.ca> Date: Tue, 16 Jun 2026 23:44:20 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb/remote: fix assertions when attaching in non-stop mode To: Martin KOCH , gdb-patches@sourceware.org References: <20260611053642.3893794-1-Martin.KOCH@bachmann.info> Content-Language: fr From: Simon Marchi In-Reply-To: <20260611053642.3893794-1-Martin.KOCH@bachmann.info> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 6/11/26 1:36 AM, Martin KOCH wrote: > When connecting to a remote target in non-stop mode against a > multi-threaded inferior stopped at raise(SIGSTOP), three internal-error > assertions can fire in sequence: > > remote.c:546: mark_async_event_handler: Assertion 'this->is_async_p ()' failed. > thread.c:429: set_pending_waitstatus: Assertion 'this->internal_state () == > THREAD_INT_STOPPED || ...' failed. > thread.c:426: set_pending_waitstatus: Assertion '!this->has_pending_waitstatus ()' failed. > > The first one is what PR 30630 reports and is fixed with the PR proposed > by Mikhail Terekhov, but with the fix the two other assertions surface: > > * thread.c:429: addressed by reordering set_internal_state / set_state > to run before set_pending_waitstatus. > * thread.c:426: addressed by clearing any existing pending wait > status before installing the new one, when gdbserver delivers > multiple events for the same thread. > > [1] https://sourceware.org/pipermail/gdb-patches/2023-October/202937.html > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30630 > Signed-off-by: Martin KOCH Hi Martin, We will definitely want a test for this. I played with the reproducer a little bit, I think that the target_is_async_p and the reorder set_internal_state vs set_pending_waitstatus fixes make sense. For the "clear duplicate waitstatus" one, I'd like to understand the root cause a bit better. The fix is not necessarily bad, in order to protect against misbehaving remotes, but I'm thinking that if GDB really sees duplicate stop replies for a given thread, then perhaps gdbserver is doing something wrong that should also be fixed. I looked at the RSP logs, and saw this: [remote] Sending packet: $?#3f [remote] Packet received: T1206:e0419624fd7f0000;07:b8419624fd7f0000;10:520aaa1ba67f0000;thread:p194d4.194d4;core:a; [remote] Sending packet: $vStopped#55 [remote] Packet received: T1206:c0ed9f1ba67f0000;07:98ed9f1ba67f0000;10:520aaa1ba67f0000;thread:p194d4.194d5;core:d; [remote] Sending packet: $vStopped#55 [remote] Packet received: OK Seems fine, one event for each thread. But I scrolled up and saw: [remote] Sending packet: $QNonStop:1#8d [remote] Packet received: OK [remote] Sending packet: $qXfer:threads:read::0,1000#92 [remote] Notification received: Stop:T1206:e0419624fd7f0000;07:b8419624fd7f0000;10:520aaa1ba67f0000;thread:p194d4.194d4;core:a; [remote] Packet received: l\n\n\n\n [remote] Sending packet: $vStopped#55 [remote] Packet received: OK That's probably it: early on, GDB sent an asynchronous stop reply for one of the threads. So here, I end up with two stop replies for thread 194d4. On page https://sourceware.org/gdb/current/onlinedocs/gdb.html/Remote-Non_002dStop.html#Remote-Non_002dStop we read: In non-stop mode, the target shall respond to the ‘?’ packet as follows. First, any incomplete stop reply notification/‘vStopped’ sequence in progress is abandoned. The target must begin a new sequence reporting stop events for all stopped threads, whether or not it has previously reported those events to GDB. The first stop reply is sent as a synchronous reply to the ‘?’ packet, and subsequent stop replies are sent as responses to ‘vStopped’ packets using the mechanism described above. The target must not send asynchronous stop reply notifications until the sequence is complete. If all threads are running when the target receives the ‘?’ packet, or if the target is not attached to any process, it shall respond ‘OK’. I could be wrong, but my interpretation of the "target must not send asynchronous stop reply notifications until the sequence is complete" part is that gdbserver should refrain from sending async stop replies until GDB has sent packet ? and the whole dialog for packet ? is over. So that would be a gdbserver bug. Another way to interpret the sentence could be that the target must not send async stop replies only during the window that starts when receiving the ? packet and ends when sending the final OK that ends the ? dialog. But that would be surprising. If we agree it's a gdbserver bug, then ideally we would have: - patch that fixes the gdbserver bug - patch that fixes the other two asserts, with a test (it should work fine at this point) - optionally, patch that adds handling for duplicate stop replies / misbehaving targets To test the last one, it is always possible to add knobs to gdbserver to make it misbehave on purpose. Or, there are tests that run the program once to record the RSP communication (for use with gdbreplay), modify the log to insert something wrong (like here, you could make the target send back two stop replies for the same thread), and replay using gdbreplay. But this is starting to sound like some scope creep, if we just had the first two I'd be happy. Also, I just saw that patches 2 and 3 in Mohamed's series here are basically the same fixes as you. https://inbox.sourceware.org/gdb-patches/20260518183316.127043-1-mohamed.bouhaouel@intel.com/M Either way, I think it would be good to have a test based on the reproducer in bug 30630. Thanks, Simon