From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id DZNiHebCQWgGJQIAWB0awg (envelope-from ) for ; Thu, 05 Jun 2025 12:16:38 -0400 Received: by simark.ca (Postfix, from userid 112) id 61AF31E102; Thu, 5 Jun 2025 12:16:38 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-9.0 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED, RCVD_IN_VALIDITY_RPBL,RCVD_IN_VALIDITY_SAFE,WEIRD_PORT autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (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 960E61E0C2 for ; Thu, 5 Jun 2025 12:16:37 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1087F3858C98 for ; Thu, 5 Jun 2025 16:16:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1087F3858C98 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by sourceware.org (Postfix) with ESMTPS id E69DA3858D37 for ; Thu, 5 Jun 2025 16:15:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E69DA3858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E69DA3858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.128.41 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1749140158; cv=none; b=A4Y2dkbraCaPTFq9E6GE0q0AmX/LViP+jr5HjYX8H+wEc3bQzIgmqev5ryePKkLxX1PlrhtZ9Ddpb0QqGdbc9E0x/nSBnFLcUwat23j6Dtp86LjXEAo0JC39wInhmb6oW8mjrEeJ1ZpW7JgY8FK5lZ5LLkJrQSNi9QJKHNBBIIw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1749140158; c=relaxed/simple; bh=eUgHou1Rd50BmRvFDeFBeWJmst6L/37qT33qdGdZzYM=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=NSlhxib8KlGewOFqBVmAcSyHSEbuzOUFl9Y/TCCrlmUQ21aM7J0rnRnta7PhevdEbRQCEXkMCD0157R11b33qAeHCGjTVGEyDD1pHxLnNFfTGq9dXq1xWmdmDNMV1qfTAl8AqXSdpGhnUeb5uPTyWe7bqe1O2z3Ivf4iRhuVS3A= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E69DA3858D37 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-43edecbfb94so13133575e9.1 for ; Thu, 05 Jun 2025 09:15:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749140157; x=1749744957; h=content-transfer-encoding:in-reply-to:content-language:from :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qQ5reUjYAnil0aaOhoYlNZoXOfrAs6bh4VTLBfQp9Ts=; b=UVej/6pLG1BFRywUNY9w5ZfZSlnQhzRTtX2J7KcxjuDRvmFAqNK2Rck351RRDIItq/ 4IhAGsFsCxZJYTNn+rPweJHrtkQWLEp4y/9xrsxlh2EwpspiAZabG5UZGhh9mcuR5GKX vYlo38dzhRy4Xf4HA2vy0X72j65c49ViH+yPOExzhUz1fhx4EiO3H2SkIutLQVK0a36H pMC6BeU0RRp8uyH2RgTAOWrTKZGSZtLj+Ga8iP3tCl8PBsJ58yXtmK4AVpfAgKD7g+Ix 8gCI9UlEohB2MtFb0t8z2aveQviEqv7UwCInMUV5ob77uRB+C8CuA5VDDv01B4NBVew6 K+eg== X-Forwarded-Encrypted: i=1; AJvYcCVSqvcVu/tm60h5L3wTQIKPa8DOsPg+5QX0M1UkQIuSi9OKEZSiwX7nv8SIa0wsXllpaMzCUFH94B6Osw==@sourceware.org X-Gm-Message-State: AOJu0YwbTqYQhOm2wWX2d6JnbIkQ+C4XDTQRFvQG8+33Z4ffoS+Cu/Cg hj1Y/Oumy7zxkfsBUhpn8TevLYcclN1t6cMRSBHUVLsQCQ8Cp0NN3WQl4XKb7VLQ X-Gm-Gg: ASbGncuRmMYYEEF13Oh1vGZbbXCg9lGV1eZsV0Tkyaf8uRhxayy1DxVX5veCp/tMIAP 5DCf/LSNCyF1fiCNTwWWA9G8i3BFzg//CEzajT9NdGJ9WWSG4T+i/YRumWyA8DXY5AxU6ZHkH/K RaisIFDsKIXrh6K5NpukT5N8TpeRjtJ0Ycck4LqGRMBDTpw4O7RifEbGs4Okbultxt1jTkq+yMf JQ4nioEYBZgw64c5GmgzzBEZcF+SBoSavi82Hkw2Ldt1aF65xcXtSNBkranWzc9KCpPTh5Of1t1 Ta/pTIDnoyXdEF03+YKgOwjbxyYrCH4e7VSJzjESQzT5NUzCPMV6D/6wzwGPDlObBLL+2dBK8Ld V0Oa7GZ9VdbcikKVcPUx7XdEijGmKZA== X-Google-Smtp-Source: AGHT+IHq9DRPF/RQxJNOEdqJdy62u/en5UX8MMd/6NAwDZYGYTbkZYKRr8Fh5mcCxC3mv2DO58BA0w== X-Received: by 2002:a05:600c:6298:b0:43c:fe15:41cb with SMTP id 5b1f17b1804b1-451f0ac62ddmr74846845e9.15.1749140156349; Thu, 05 Jun 2025 09:15:56 -0700 (PDT) Received: from ?IPV6:2001:8a0:facf:2b00:451a:975e:a6cb:7552? ([2001:8a0:facf:2b00:451a:975e:a6cb:7552]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4f009752esm24884634f8f.74.2025.06.05.09.15.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Jun 2025 09:15:55 -0700 (PDT) Message-ID: Date: Thu, 5 Jun 2025 17:15:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] [gdb/tdep] Don't call WaitForSingleObject with INFINITE arg To: Tom de Vries , gdb-patches@sourceware.org References: <20250605150330.26246-1-tdevries@suse.de> From: Pedro Alves Content-Language: en-US In-Reply-To: <20250605150330.26246-1-tdevries@suse.de> 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 2025-06-05 16:03, Tom de Vries wrote: > I decided to try to build and test gdb on Windows. > > I found a page on the wiki ( https://sourceware.org/gdb/wiki/BuildingOnWindows > ) suggesting three ways of building gdb: > - MinGW, > - MinGW on Cygwin, and > - Cygwin. > > I picked Cygwin, because I've used it before (though not recently). > > I managed to install Cygwin and sufficient packages to build gdb and start the > testsuite. Cool! FYI, I cross build from Linux using this: https://github.com/palves/cygwin-cross and then test from Cygwin, by: - smb mounting the sources from linux - configuring only the testsuite, not the whole gdb (src/gdb/testsuite/configure) - copying over gdb.exe to the Windows box (via rsync) - pointing at the copied gdb with make check GDB=.../gdb.exe I do this because building on Linux is so much faster. > > However, testsuite progress ground to a halt at gdb.base/branch-to-self.exp. > [ AFAICT, similar problems reported here [1]. ] The testsuite fails to kill gdb all the time for me, it may well be the same. I'll give it a try after you've merged it. Ecstatic that you found this! > > I managed to reproduce this hang by running just the test-case. > > I attempted to kill the hanging processes by: > - first killing the inferior process, using the cygwin "kill -9" command, and > - then killing the gdb process, likewise. > > But the gdb process remained, and I had to point-and-click my way through task > manager to actually kill the gdb process. > > I investigated this by attaching to the hanging gdb process. Looking at the > main thread, I saw it was stopped in a call to WaitForSingleObject, with > the dwMilliseconds parameter set to INFINITE. > > The backtrace in more detail: > ... > (gdb) bt > #0 0x00007fff196fc044 in ntdll!ZwWaitForSingleObject () from > /cygdrive/c/windows/SYSTEM32/ntdll.dll > #1 0x00007fff16bbcdcf in WaitForSingleObjectEx () from > /cygdrive/c/windows/System32/KERNELBASE.dll > #2 0x0000000100998065 in wait_for_single (handle=0x1b8, howlong=4294967295) at > gdb/windows-nat.c:435 > #3 0x0000000100999aa7 in > windows_nat_target::do_synchronously(gdb::function_view) > (this=this@entry=0xa001c6fe0, func=...) at gdb/windows-nat.c:487 > #4 0x000000010099a7fb in windows_nat_target::wait_for_debug_event_main_thread > (event=, this=0xa001c6fe0) > at gdb/../gdbsupport/function-view.h:296 > #5 windows_nat_target::kill (this=0xa001c6fe0) at gdb/windows-nat.c:2917 > #6 0x00000001008f2f86 in target_kill () at gdb/target.c:901 > #7 0x000000010091fc46 in kill_or_detach (from_tty=0, inf=0xa000577d0) > at gdb/top.c:1658 > #8 quit_force (exit_arg=, from_tty=from_tty@entry=0) > at gdb/top.c:1759 > #9 0x00000001004f9ea8 in quit_command (args=args@entry=0x0, > from_tty=from_tty@entry=0) at gdb/cli/cli-cmds.c:483 > #10 0x000000010091c6d0 in quit_cover () at gdb/top.c:295 > #11 0x00000001005e3d8a in async_disconnect (arg=) > at gdb/event-top.c:1496 > #12 0x0000000100499c45 in invoke_async_signal_handlers () > at gdb/async-event.c:233 > #13 0x0000000100eb23d6 in gdb_do_one_event (mstimeout=mstimeout@entry=-1) > at gdbsupport/event-loop.cc:198 > #14 0x00000001006df94a in interp::do_one_event (mstimeout=-1, > this=) at gdb/interps.h:87 > #15 start_event_loop () at gdb/main.c:402 > #16 captured_command_loop () at gdb/main.c:466 > #17 0x00000001006e2865 in captured_main (data=0x7ffffcba0) at gdb/main.c:1346 > #18 gdb_main (args=args@entry=0x7ffffcc10) at gdb/main.c:1365 > #19 0x0000000100f98c70 in main (argc=10, argv=0xa000129f0) at gdb/gdb.c:38 > ... > > In the docs [2], I read that using an INFINITE argument to WaitForSingleObject > might cause a system deadlock. Wow, unbelievable. Thanks a lot for going all the way and finding this. > > This prompted me to try this simple change in wait_for_single: > ... > while (true) > { > - DWORD r = WaitForSingleObject (handle, howlong); > + DWORD r = WaitForSingleObject (handle, > + howlong == INFINITE ? 100 : howlong); > + if (howlong == INFINITE && r == WAIT_TIMEOUT) > + continue; > ... > with the timeout of 0.1 second estimated to be: > - small enough for gdb to feel reactive, and > - big enough not to consume too much cpu cycles with looping. > > And indeed, the test-case, while still failing, now finishes in ~50 seconds. > > While there may be an underlying bug that triggers this behaviour, the failure > mode is so severe that I consider it a bug in itself. > Yeah. The documentation talks about the the case of the code spawning windows, which I don't think we do. But still. I've seen so many weird things on Windows... It's just one more. > Fix this by avoiding calling WaitForSingleObject with INFINITE argument. Approved-By: Pedro Alves