From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 4mq5EISVQmjw5AIAWB0awg (envelope-from ) for ; Fri, 06 Jun 2025 03:15:16 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=Vr8HDX4f; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=dTpzxr3y; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=FIftSQ0N; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=z/5Zx1bC; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 2BACF1E11C; Fri, 6 Jun 2025 03:15:16 -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.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 E468F1E089 for ; Fri, 6 Jun 2025 03:15:14 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A40493857839 for ; Fri, 6 Jun 2025 07:15:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A40493857839 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=Vr8HDX4f; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=dTpzxr3y; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=FIftSQ0N; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=z/5Zx1bC Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by sourceware.org (Postfix) with ESMTPS id E82763857820 for ; Fri, 6 Jun 2025 07:12:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E82763857820 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E82763857820 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.135.223.131 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1749193933; cv=none; b=MDTwomyxYcYc8tD//I/AwFrj/3XUQsGHwbmuVMFugA5Sj9x8cSa8abWHIzQ/RJCM1eLzfG1h3B0M0fYPRrqJBL3ZkaMXA84VHQJGem9qVW0gpi0KNFTwz2bpCnBHYqRhT91lxzlhSsQ4zD3QxXQmWVx/PqKGpkd4l8EfzmNcFyM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1749193933; c=relaxed/simple; bh=uNpFrmu6oagw3RY3xDspU41c3GJSA4T0WF6ysANO6ms=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature: Message-ID:Date:MIME-Version:Subject:To:From; b=FrZpSKD7tyKjE7KvHZX1FG/Ag21bexRJXL+vl0kdfBgh9kLbdRfDqUbGFnzQiYvY05TW53RXuiG0X/NqFAU9y5UyeUq5sHZJdXD+r2HfGcaCw6wvdcy/QMXM4c+XKJ3cB3ZEUC2XfA6hVWMcPgK5S0oqjDcjhA0Ao/rbPb4e9wk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E82763857820 Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id D90151F46E; Fri, 6 Jun 2025 07:12:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1749193932; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NCBRHQumdZMNuXeRfPIkWorMwJ6LdXRYk23u5dPaXVw=; b=Vr8HDX4fGCak3/G1Pf9tKbA39bcmQGGjqdplCf3zNFGKZmHUlUYCERHpwIPLiP7S6Wpi64 OB2KteBmoEGWTGGwzTEhZ2YvZBoM58uIHmb8/wJsn4UEKmuJvm+wAPO/onsvzlNugN8fCg TaNOy0/x1xW/ocF2Bl59f9snW/6xZtU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1749193932; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NCBRHQumdZMNuXeRfPIkWorMwJ6LdXRYk23u5dPaXVw=; b=dTpzxr3yjREgjLhaRKTU+i9bMcf+07Hvd2XG5UE6jGGq0B35rKhtme1auGaFztb/66Kg0s V7ZhI/TW+oo5GVAA== Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1749193931; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NCBRHQumdZMNuXeRfPIkWorMwJ6LdXRYk23u5dPaXVw=; b=FIftSQ0NXQVcCoBa8uEBPns9tguTrFODNl7ULwNag9O9Oh6lgnDPgIy98q7Z1cfXvACmfe wGDVa94eaBUKU84wTcwr8VkwZPaxgxP5zfMK/i8mJw6baz0zIGXukBinO273r4XpPEoabF V6QVO8+/zTXguokN6DIGj0YHM0WreJE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1749193931; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NCBRHQumdZMNuXeRfPIkWorMwJ6LdXRYk23u5dPaXVw=; b=z/5Zx1bC82QTgfBJ5J46uY1tQiETeYDokBaQsRtAvRWWGdrx8YCi6X9k0K+UXH90EkUBM9 h5DSotVmY7GsYDDg== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id BE9C11336F; Fri, 6 Jun 2025 07:12:11 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id Gg0YLMuUQmiqagAAD6G6ig (envelope-from ); Fri, 06 Jun 2025 07:12:11 +0000 Message-ID: <4311a30a-51cc-4054-8219-48f895bd962f@suse.de> Date: Fri, 6 Jun 2025 09:12:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] [gdb/tdep] Don't call WaitForSingleObject with INFINITE arg To: Pedro Alves , gdb-patches@sourceware.org References: <20250605150330.26246-1-tdevries@suse.de> Content-Language: en-US From: Tom de Vries In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-4.30 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; FUZZY_BLOCKED(0.00)[rspamd.com]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[sourceware.org:url, imap1.dmz-prg2.suse.org:helo] 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/5/25 18:15, Pedro Alves wrote: > 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. > Hi Pedro, yeah, things are slow indeed, and thanks for sharing this setup. For now, I'll stick with the basic setup, and leave optimizations for later. >> 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! > Yeah, I hope that this helps :) FWIW, I've ran the testsuite again, and got stuck this time at gdb.base/catch-fork-kill.exp. In this case, the problem didn't seem to be gdb, but lingering test execs. After killing those manually using "kill -9", the test-case finished. The hang can be fixed by adding a missing "require supports_catch_syscall". I was wondering, I saw you mention "I've got another series of patches to improve such tests and skip others, and that's what I've been testing with". Do you have similar fixes in that series? If so, can you submit them, or share them in a branch? >> 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 > Thanks for the review. - Tom