From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id A5BBGsydTmr/sCwAWB0awg (envelope-from ) for ; Wed, 08 Jul 2026 14:58:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1783537100; bh=/D3Uv8lYCb+5slNVfcYrJZTum4V+W1W7drK1DTwVXnk=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=tRWS3PqqDZbTN2R2eOeHplNCfP/+FTMPld4to8p8KwTw3rTUKYN//zfNjSvHd6V/G 1tgMyxqUmx9zTwNRUQtSYeoK0c3pgCHUvAxtnuyZtNy2FNzVW5cCNXT1+RZT5tDXQt LexTpWwxqQKRO4KsY/JnLOeYil1/XXalJOUkSrcc= Received: by simark.ca (Postfix, from userid 112) id 59F461E04F; Wed, 08 Jul 2026 14:58:20 -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=KfCw49zS; dkim-atps=neutral Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::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 66A271E04F for ; Wed, 08 Jul 2026 14:58:19 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 73CBB4BA2E2C for ; Wed, 8 Jul 2026 18:58:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 73CBB4BA2E2C 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=KfCw49zS Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 086384BA2E09 for ; Wed, 8 Jul 2026 18:57:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 086384BA2E09 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 086384BA2E09 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=1783537074; cv=none; b=dN+iTSPKbibhRaCzedlC9eTLnHsjhqb8Pz1MfwE8o8QIryA1nq7psVxYtFQzkwM9GVT3tnCezrpdcelzL5uOD5NbSVNxLvzKPpdeanoYQfnQyR4XdxUYcUw7gSa7xUwQ67opSLEyK1doIOFLYdenHGLmjrd9c/o9uTlwXATeazo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1783537074; c=relaxed/simple; bh=/D3Uv8lYCb+5slNVfcYrJZTum4V+W1W7drK1DTwVXnk=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=mkyNKkVJ/tuTvYKTaM8UB9bwvUkgAUB4kSHlbTp9LclJpMQjDwq6/2AmXbTIkl9/xhDNP0BZieO02eFnRhcCPtnqxv0V5HMTfkt3u6RsK9JeQIeTZeJBuSD667qwOtoMsEqZXFLinVdoZr0S/st8uujXSn+bf4GOBJcb7zyMXmM= 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=KfCw49zS DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 086384BA2E09 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1783537072; bh=/D3Uv8lYCb+5slNVfcYrJZTum4V+W1W7drK1DTwVXnk=; h=Date:Subject:To:References:From:In-Reply-To:From; b=KfCw49zSIml2oVPu4/tg5fkq66QqwoYzfC/lt69YT1naqJAZ6I9QyzSu0qbM5iqIl H8Cnq21SRs8v1B00IFKA+R4j1mTq8tvDRRsuHAAWcD4u18U2FQmUjrB7qwV47erwW2 ZeXJl67XHKOcJwAM+JyhmoWrhHL/PB0MdZbNjtGo= Received: by simark.ca (Postfix) id 02D5F1E04F; Wed, 08 Jul 2026 14:57:51 -0400 (EDT) Message-ID: Date: Wed, 8 Jul 2026 14:57:51 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] gdb/remote: fix assertions when attaching in non-stop mode To: Martin KOCH , gdb-patches@sourceware.org References: <15e03eb6-40b4-4f69-a96b-57e3650e021f@simark.ca> <20260619092535.2476689-1-Martin.KOCH@bachmann.info> Content-Language: fr From: Simon Marchi In-Reply-To: <20260619092535.2476689-1-Martin.KOCH@bachmann.info> 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 6/19/26 5:25 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. As mentioned in me previous message, the root cause of this is likely a bug in gdbserver. It's good to make gdb resilient against bugs on the remote side, but I wouldn't want to merge this in gdb before fixing the gdbserver bug. Otherwise, it will get forgotten about and it will never get fixed. > These assertions are reached through > remote.c:process_initial_stop_replies, which only runs on the initial > connection to a remote target, not via GDB's own "attach" command. The > new test gdb.threads/attach-non-stop-stopped.exp reproduces the issue: > it starts gdbserver attached to a multi-threaded inferior that is > already stopped via a pending SIGSTOP, then connects GDB to it in > non-stop mode. Without this fix the connection trips the assertions > above; with it, the connection succeeds. > > [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 > --- > gdb/remote.c | 14 ++- > .../gdb.threads/attach-non-stop-stopped.c | 78 +++++++++++++ > .../gdb.threads/attach-non-stop-stopped.exp | 104 ++++++++++++++++++ > 3 files changed, 191 insertions(+), 5 deletions(-) > create mode 100644 gdb/testsuite/gdb.threads/attach-non-stop-stopped.c > create mode 100644 gdb/testsuite/gdb.threads/attach-non-stop-stopped.exp > > diff --git a/gdb/remote.c b/gdb/remote.c > index 2961664cf33..4148301bc6f 100644 > --- a/gdb/remote.c > +++ b/gdb/remote.c > @@ -5237,13 +5237,17 @@ remote_target::process_initial_stop_replies (int from_tty) > ws.set_stopped (sig); > } > > - if (ws.kind () != TARGET_WAITKIND_STOPPED > - || ws.sig () != GDB_SIGNAL_0) > - evthread->set_pending_waitstatus (ws); > - > set_internal_state (this, event_ptid, THREAD_INT_STOPPED); > set_state (this, event_ptid, THREAD_STOPPED); > get_remote_thread_info (evthread)->set_not_resumed (); > + > + if (ws.kind () != TARGET_WAITKIND_STOPPED > + || ws.sig () != GDB_SIGNAL_0) > + { Here, add a comment like: /* This should not happen, but a misbehaving remote could send duplicate stop replies for a given thread. We arbitrarily keep the last one. */ > + if (evthread->has_pending_waitstatus ()) > + evthread->clear_pending_waitstatus (); > + evthread->set_pending_waitstatus (ws); Newline after the if. > +# GDB survived the connection. As a sanity check, confirm it is > +# responsive and that all threads are present. > +for {set attempt 0} {$attempt < 10} {incr attempt} { > + set thread_count 0 > + gdb_test_multiple "info threads" "" { > + -re "\r\n\[ *\]+$decimal\[ \t\]+(Thread|LWP|process)\[^\r\n\]*" { > + incr thread_count > + exp_continue > + } > + -re "$gdb_prompt " { > + } > + } > + if {$thread_count >= $total} { > + break > + } > + sleep 1 > +} What is the reason for the "attempt" loop and the sleep? Shouldn't all threads be visible from the start? Simon