From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 5v8ZK8Au62n3eTgAWB0awg (envelope-from ) for ; Fri, 24 Apr 2026 04:50:08 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=FZVq4WM1; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 8D9BC1E067; Fri, 24 Apr 2026 04:50:08 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,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 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 1BAB11E067 for ; Fri, 24 Apr 2026 04:50:06 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 6AF184BB24D2 for ; Fri, 24 Apr 2026 08:50:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6AF184BB24D2 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=FZVq4WM1 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 759054B9DB7F for ; Fri, 24 Apr 2026 08:49:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 759054B9DB7F Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 759054B9DB7F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777020578; cv=none; b=H+FRgIJzWAjaCj9yrTj43TpdP4HzTbfFT1XBSsAajnFcyJc+axun1jqCDGA5E8hc5rGr/itXvnIaV0wDQqsf0h3HIjDoSaJxJnq2Vr5lVUBAx0Pwnawg4zFKEmVBLYO/NexcYa7FPRzK++9ho/tJ+aHkqTlZ2e79Qo+HRihd7x0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777020578; c=relaxed/simple; bh=YVlqKSAxcadOylm1xTogX9vepTZC0MsYt07rzbb1/4c=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=F2R6xbfdZF1rpkhBYthqTj14ZPw8gndfv9rfm6Xg48jOG6njM25JMV+09i+4yxc1AtjZZIx+9yyaQjx5ZJWFswzEs53RY2mOG670IQ/dBuni0v9QqoRjQDB0H+NhvHIWhFJBoBBsgSwWIfbnZg7tAklG+6+glvP7Nqv5T5ylIs4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 759054B9DB7F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1777020578; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fWc+FdgPXH7d455VbX+l4ZnEwJt/aQDOXbHErAziSuk=; b=FZVq4WM1gLzajAbhdgas8+10kSRoyL4TmCf8Gj+IPbs1swKK3Brx0laFzKxAsbW1TCVFIR P0qagFIN19p4m0lGXBw3kuyZPD9DA0xgyoRP9lJJQ9QSVprerCTv67St+3F+VqmTmbPxII zWcQ305gB7cZ8NWnGsRfJ/0I4JmK1Vc= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-423-zJbwOL7wOmG7HZ9p6FNf4g-1; Fri, 24 Apr 2026 04:49:37 -0400 X-MC-Unique: zJbwOL7wOmG7HZ9p6FNf4g-1 X-Mimecast-MFC-AGG-ID: zJbwOL7wOmG7HZ9p6FNf4g_1777020576 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-488bd1ee9e7so64336495e9.1 for ; Fri, 24 Apr 2026 01:49:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777020575; x=1777625375; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fWc+FdgPXH7d455VbX+l4ZnEwJt/aQDOXbHErAziSuk=; b=D1oSFCsxlOs8HGbwwIXIiz7v5TIuXl3lvJqGW3uG8Amb7HpbSKWxi4gD6h+jHf1Wgd 7pYe0SikFRftgvTkDTohDmFtHmjmRKoJBBBVk3YITn0W5UAZ0S40jP03rxp1LN/P7y5y OiF5OUB8YZWFeZhnp6TLNCKNNNeiQ0szIzraFv/ty+rcWpKLsJNJPprrOfDhxlDZh3Tw 7msREBSsEp9iT1MXPVY/7dYr5/hUanm1oxmSwSdmZpkt9b6+1ly6gifb45QJMiGfWydj D/enUj7haUdxwT/kMeBsDkncxFN9aEM9+84LX/bAK3HeGC37sXJ6mIh54cuT9V2vPMP7 Zw5g== X-Forwarded-Encrypted: i=1; AFNElJ96fiERR9OVsa6IknrxtFEn3p6s0x/cN1Xe4+ZAAz5i8j4lcFVsgd0cdnHnoZbE5lVs6U1jknkuF/5oeQ==@sourceware.org X-Gm-Message-State: AOJu0Yw80afAzd4WfxD4OS4eZn5fAyRa9MVYl/Ye3YSl+sJc8lw3mMkk nMB/C9NzVSDgF4G2FtgOiXxRQKRDqIYAY2YdeXa3NQRfq7Et2ouVC8n+v/Nypoq1Knj0t+NG7ja MTqluOY/YigI61miDNyEtpIUoQPh/wD+1yLgaynNrUK4skAjbbpUTzYZJMWLcwd1Lsy49HbI= X-Gm-Gg: AeBDiesYx4GA5OMt0ZKKixlPqQoztrKQuDi7FBPFiXZ7dXbfm2hvDkhJL3ZLgvvwPZ/ fEu2fiqFGyms8QcShcxbV85iJHUYLSHIMPnea7G+rfdOXVQsTLOwqQe34onbJPCX2f4qbMW+4CW /nLxf4b+g1a8ujfWwdLSBUTT3qBTqPjfgsrKNWR1Muvvcyuw9SADlgCOzssBGK0PUJMolHHwfzk tz8aGvVIL3OL82u0zbAhBpcrRTZv73MqwZDBprBwr3C4sUEcxyxn08nzmV+VgqdNamOWgKPXi5i i3nGwc+o2uqCIEBw8O6RIC9QUaAkMPUQMH1f/0vywDGpZuCNNjjd4lKoZFw3RRvZYqiXknxNzUC 96x1t4DED3HrTlsj2fPahOqasPWQ= X-Received: by 2002:a05:600c:530f:b0:48a:56de:d640 with SMTP id 5b1f17b1804b1-48a56dedc17mr223389625e9.16.1777020575485; Fri, 24 Apr 2026 01:49:35 -0700 (PDT) X-Received: by 2002:a05:600c:530f:b0:48a:56de:d640 with SMTP id 5b1f17b1804b1-48a56dedc17mr223389015e9.16.1777020574928; Fri, 24 Apr 2026 01:49:34 -0700 (PDT) Received: from localhost ([31.111.84.232]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48a557412eesm117343775e9.9.2026.04.24.01.49.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Apr 2026 01:49:34 -0700 (PDT) From: Andrew Burgess To: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [PATCH] Don't pretend infcalls don't set the inferior running (PR gdb/34082) In-Reply-To: <20260423184946.1128623-1-pedro@palves.net> References: <20260423184946.1128623-1-pedro@palves.net> Date: Fri, 24 Apr 2026 09:49:33 +0100 Message-ID: <87zf2s215u.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: -cmDEI70xgatVwjsN-dRtgLAQKB24Q5UR1_jbIcPxlY_1777020576 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 Pedro, Thanks for fixing this. No real problems, one trivial nit, and a question, see below... Pedro Alves writes: > Commit 2954dd2b73 ("thread_info::executing+resumed -> > thread_info::internal_state"), caused a regression in > gdb.threads/hand-call-new-thread.exp: > > ... > (gdb) PASS: gdb.threads/hand-call-new-thread.exp: iter 1: no thread marked running > p new_thread () > .../src/gdb/infrun.c:3742: internal-error: proceed: Assertion `!thread_is_in_step_over_chain (&tp)' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > ----- Backtrace ----- > FAIL: gdb.threads/hand-call-new-thread.exp: iter 2: gdb-command

(GDB internal error) > ... > > This commit fixes it. > > Let's say we have three threads, 1, 2, and 3. User does: > > (gdb) continue > > This makes GDB switch all three threads to THREAD_RUNNING. > > If some of those threads, now running, spawns a new thread, that > thread is also set to state THREAD_RUNNING. We end up with four > threads marked THREAD_RUNNING. > > If e.g., threads 2 and 3 both hit a breakpoint that needs to be > stepped over (e.g., condition evals false), and there is only one > displaced-stepping slot, then one thread starts a displaced stepping > sequence, while the other is put in the step-over queue, waiting for > its turn. > > Now, if meanwhile thread 1 hits a user-visible stop, GDB stops all > threads, and transitions all their states to THREAD_STOPPED. Any > thread that was still waiting for its turn in the step-over queue is > removed from the queue. That happens in the THREAD_RUNNING => > THREAD_STOPPED transition, here: > > thread_state > thread_info::set_state (thread_state state, bool suppress_notification) > { > ... > switch (m_state) > { > case THREAD_STOPPED: > if (thread_is_in_step_over_chain (this)) > global_thread_step_over_chain_remove (this); > > The next time the user continues execution, if the breakpoint is still > inserted, proceed() sets them stepping the breakpoint again. And > again, if there is more than one thread that needs to step-over, and > there aren't enough slots, some threads may end up in the step-over > queue. Rinse, repeat. > > All this works well with normal resumption commands, like continue, > step, next, etc. > > The problem exposed by gdb.threads/hand-call-new-thread.exp is if you > resume execution with an infcall instead of a normal execution > command. In that case, proceed() skips transitioning (pre-existing) > threads to THREAD_RUNNING, here: > > proceed (CORE_ADDR addr, enum gdb_signal siggnal) > { > ... > /* Even if RESUME_PTID is a wildcard, and we end up resuming fewer > threads in RESUME_PTID are now running. Unless we're calling an > inferior function, as in that case we pretend the inferior > doesn't run at all. */ > if (!cur_thr->control.in_infcall) > set_state (resume_target, resume_ptid, THREAD_RUNNING); > > So later, when the call finishes for any reason (normal call finish, > or some other user-visible stop happens), and GDB transitions all > threads to THREAD_STOPPED, we hit the early return in > thread_info::set_state: > > thread_state > thread_info::set_state (thread_state state, bool suppress_notification) > { > thread_state prev_state = m_state; > if (prev_state == state) > return prev_state; // <== EARLY RETURN > > m_state = state; > switch (m_state) > { > case THREAD_STOPPED: > if (thread_is_in_step_over_chain (this)) > global_thread_step_over_chain_remove (this); // NOT REACHED > break; > ... > } > } > > ... and so if any thread had been put in the step-over queue since the > last proceed(), it will incorrectly be left still in the step-over > queue, with THREAD_STOPPED state. > > If/when the user re-resumes the program again, we trip the assertion > in proceed: > > (gdb) p new_thread () > ../../src/gdb/infrun.c:3742: internal-error: proceed: Assertion `!thread_is_in_step_over_chain (&tp)' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > > Before commit 2954dd2b73 ("thread_info::executing+resumed -> > thread_info::internal_state"), this didn't happen because > set_running_thread(..., running=false) would remove threads from the > step-over queue unconditionally, even if they were already marked > stopped. > > I think the right fix is to stop pretending that infcalls don't set > the target running. I can't think of a reason we do that. It really > does run. Some thoughts: > > - I added to code to skip set_running (nowadays 'set_state(..., typo: "I added to code" -> "I added THE code" ? > THREAD_RUNNING))' for infcalls back in commit 4d9d9d0423 over 10 > years ago, but I honestly don't recall why. My guess is that it > must have been to keep backwards compatibility with something, and > the code has probably changed sufficiently since then making it no > longer necessary. > > - infcalls are always synchronous, so the intermediate running state > can't be observed with commands. I assume you mean by this that infcalls are something the user initiates from the prompt, and so while the infcall is running the user cannot also ask to inspect the thread state. I don't disagree with any of your conclusions, but, if an infcall is made as part of a breakpoint condition, then than could run in the background, asynchronously, while the user is also issuing other commands. Not that this changes anything. In this situation the user believes that the inferior is running in the background, so seeing the threads as running is absolutely fine. I'm just not convinced that the claims made in this point "infcalls are always asynchronously" and "the intermediate running state can' be observed" are correct. But the patch itself makes a lot of sense, and looks good. Approved-By: Andrew Burgess Thanks, Andrew