From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Q/phKxM4iWplTDUAWB0awg (envelope-from ) for ; Sat, 22 Aug 2026 01:48:03 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=mses2RwL; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 9D8721E09B; Sat, 22 Aug 2026 01:48:03 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.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 autolearn=ham autolearn_force=no version=4.0.1 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 A93261E09B for ; Sat, 22 Aug 2026 01:48:02 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B2ED14BB24CD for ; Sat, 22 Aug 2026 05:48:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B2ED14BB24CD Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=mses2RwL Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id F3A274BA23FC for ; Sat, 22 Aug 2026 05:47:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F3A274BA23FC Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F3A274BA23FC Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1787377658; cv=none; b=hRU0+q0c5caq3eKsQYuf7q3wjSc9KH/rhWyKZc777PZ+S3GIr993wUl8scND0EATiTsBCfHpQZNdZFj2Ve6AQ/InZ9zlRg0sqfiTpWqvtC1BygBQOA96LSdu0S6AOfBL+4jBIvMF16WXbVWtZOgDYyg0DF0EfWQE/0fwAYKwCHo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1787377658; c=relaxed/simple; bh=eYZRS26+iTHTgpHlKzZIFKvF6xAx1wHzc5RDPw06b1I=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=UoktGcqbdhtuefitUwIXz0nH5zYUW16RhPDB136TFNre7WjokjeEeUrssi0lMMoSCmu6XF4Au/+qRRP7/fsj7/yKLhRpJ2Fqtx5kl4v5cpAQkL853/qzP4j065CqrH6+WEZ0Cpo7/EkRDqJtsHwYPNJXelMrpIuJsmtW+gjGZCQ= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=mses2RwL DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F3A274BA23FC Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wxeZt-0004hC-3x; Sat, 22 Aug 2026 01:47:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=wfzX9T4C3Rt/yl2gJWbfzeWVI8wj8RC0D8jlJmKqOoA=; b=mses2RwLVS1C LUN/zkJusdfmFvVYgiJBAukmikImb2ExNUNq73MtPpoN1FP4caPxwA08GNQIvbXGaz9+ciGBTsF1n +wyvX5EuTnkxDIXGOM0lmQEN7RkB3WEgnmn+A4FD1UeOcprIgqpmg/g0Wx42dnDbtAUXRuBSY1Hd4 DYq4UvAqwBdkKZC8PdClQnrtdAUVKAm2j9wB/Z2lskCOAONM57GHFE8IjpZXtCVisnhXe7wbahZi3 W1d4t12OGhQ7aT7rTlXCwtJL7ooQMTwSpwHZNu/APSbd39xW5JB4OX/Eo+9Qb2tW6o7bA0b/1Do8U VRNIkEr2ZuiG2DZOo1KilA==; Date: Sat, 22 Aug 2026 08:47:34 +0300 Message-Id: <86h5kmzoy1.fsf@gnu.org> From: Eli Zaretskii To: Tom Tromey Cc: gdb-patches@sourceware.org In-Reply-To: <87o6evpcbm.fsf@tromey.com> (message from Tom Tromey on Fri, 21 Aug 2026 12:18:05 -0600) Subject: Re: [PATCH] Ignore the last EXIT_THREAD_DEBUG_EVENT on Windows References: <20260821161828.1836622-1-tromey@adacore.com> <86mrufz7g0.fsf@gnu.org> <87o6evpcbm.fsf@tromey.com> 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 > From: Tom Tromey > Cc: Tom Tromey , gdb-patches@sourceware.org > Date: Fri, 21 Aug 2026 12:18:05 -0600 > > >>>>> "Eli" == Eli Zaretskii writes: > > Eli> How can we know that a given thread is a "final" one, when Windows is > Eli> known to start its own threads for the program being debugged? > > We track when threads are created and destroyed, and only apply this > behavior when there is a single thread remaining. Is there no possibility whatsoever that another thread will be created while we handle the termination of what we consider to be "the last thread"? Even though GDB supports scheduler-locking and non-stop mode on Windows? Also, doesn't EXIT_PROCESS_DEBUG_EVENT provide to us data about the process (like its exit code) that EXIT_THREAD_DEBUG_EVENT does not? > Eli> Are you sure there are no such threads left running after all the > Eli> threads known to GDB exit, and cause this issue? > > Yes, extracted from the log in the bug, here are all the thread and > process events: > > [windows events] get_windows_debug_event: kernel event for pid=1604 tid=0x89c code=CREATE_PROCESS_DEBUG_EVENT > [windows events] get_windows_debug_event: kernel event for pid=1604 tid=0xc20 code=CREATE_THREAD_DEBUG_EVENT > [windows events] get_windows_debug_event: kernel event for pid=1604 tid=0xc20 code=EXIT_THREAD_DEBUG_EVENT > [windows events] get_windows_debug_event: kernel event for pid=1604 tid=0x89c code=EXIT_THREAD_DEBUG_EVENT Did you succeed in capturing EXIT_THREAD_DEBUG_EVENT after receiving EXIT_PROCESS_DEBUG_EVENT this way? > >> 1. It only happened under load, I was never able to reproduce it by > >> running a single test case. > > Eli> What do you mean by "load" in this case? what kind of load? > > If I run one test case in isolation, it never fails. However if I run > the whole test suite, which defaults to running as many tests as there > are CPUs, I do see some failures. Frequently -- but not always -- the > same tests fail. Then this could be a problem due to effect of previous/other tests, which run before or in parallel with this test. In which case I'm not sure we should install this change. As you say, the OS should handle this issue for us, and the OS always knows better which thread is the last one. I worry that we could introduce a possibility of regressions if we install this workaround for a problem for which we have only insufficient understanding.