From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2a07:de40:b251:101:10:150:64:1]) by sourceware.org (Postfix) with ESMTPS id E0BF33858C29 for ; Wed, 7 Feb 2024 09:02:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E0BF33858C29 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 E0BF33858C29 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a07:de40:b251:101:10:150:64:1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707296552; cv=none; b=mYN01CkS+az1Pjr34b3PWEWZcrOkc3j7uyiOl7y22L84eRjGzEck0RhITCAA96EhdVmcz+5+p1n8PqQalmQi57vV2xs1BD/N91EYJERjA2cmqym4RCuRkNIZUnprdy5LrkQ54gTEms05bZkcYtnXfy1/ryUesKsbuD8eaNWQyGk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707296552; c=relaxed/simple; bh=n4Vv9xbJvxXfa+LiXr65NKdEVu7z2JSZ1bPhJ9YIoWc=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:From: To:Subject:Date:Message-Id:MIME-Version; b=H+pUMOS+hFkGaw7HjAcAFPo2pCeBL5vG5K9r5A0biyPzkDPzuatlRGpIob5M4E0SRKOknQqKg0TvCrWaBRU01vBXYF/q9ws6ocoEMPPepWHUXMdKcrx5bHp3IuJBgwqmdoxytg2ZE0eqXSKvIfgcDEVN6cIahdYt2/DnFPHSKXM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104: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-out1.suse.de (Postfix) with ESMTPS id AA68E222CC for ; Wed, 7 Feb 2024 09:02:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1707296548; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Bm7BNfWkj2Gf6QYX/qdmIcyCdULaoqZ82Rg2zW4Epkw=; b=Ym7mlKywTRM75kuCAXip5KR0t6V2dUDPuUfviPBDP0C9H14MkS6cENAvaGblhlEldySLJk pcsNbL4BKehkQ4dt/IKPPwPcMUN5RzNp1Xot7CiCtFJ7OScewuL2wWBj0VRyS/FVraZdva /B25gNeermd1un7A9IiDt23CJDc6R88= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1707296548; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Bm7BNfWkj2Gf6QYX/qdmIcyCdULaoqZ82Rg2zW4Epkw=; b=dJDM/7iykE9fkQR9GyLytZGi94eHxy6HTlMWV5l1x0VWvvRCyHQEHRGYHAkb+GQouUzWbx XBH4TbeHz8h4OpDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1707296548; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Bm7BNfWkj2Gf6QYX/qdmIcyCdULaoqZ82Rg2zW4Epkw=; b=Ym7mlKywTRM75kuCAXip5KR0t6V2dUDPuUfviPBDP0C9H14MkS6cENAvaGblhlEldySLJk pcsNbL4BKehkQ4dt/IKPPwPcMUN5RzNp1Xot7CiCtFJ7OScewuL2wWBj0VRyS/FVraZdva /B25gNeermd1un7A9IiDt23CJDc6R88= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1707296548; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Bm7BNfWkj2Gf6QYX/qdmIcyCdULaoqZ82Rg2zW4Epkw=; b=dJDM/7iykE9fkQR9GyLytZGi94eHxy6HTlMWV5l1x0VWvvRCyHQEHRGYHAkb+GQouUzWbx XBH4TbeHz8h4OpDg== 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 90FA513A41 for ; Wed, 7 Feb 2024 09:02:28 +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 MIkBIiRHw2XMSAAAD6G6ig (envelope-from ) for ; Wed, 07 Feb 2024 09:02:28 +0000 From: Tom de Vries To: gdb-patches@sourceware.org Subject: [RFC 1/3] [gdb/dap] Fix exit race Date: Wed, 7 Feb 2024 10:02:22 +0100 Message-Id: <20240207090224.27521-2-tdevries@suse.de> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20240207090224.27521-1-tdevries@suse.de> References: <20240207090224.27521-1-tdevries@suse.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=Ym7mlKyw; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="dJDM/7iy" X-Spamd-Result: default: False [-0.31 / 50.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_MED(-2.00)[suse.de:dkim]; R_MISSING_CHARSET(2.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[gdb-patches@sourceware.org]; BROKEN_CONTENT_TYPE(1.50)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; DKIM_TRACE(0.00)[suse.de:+]; MX_GOOD(-0.01)[]; MID_CONTAINS_FROM(1.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:dkim]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; BAYES_HAM(-3.00)[100.00%]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from] X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Spam-Score: -0.31 X-Rspamd-Queue-Id: AA68E222CC X-Spam-Level: X-Spamd-Bar: / X-Spam-Status: No, score=-12.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: When running test-case gdb.dap/eof.exp, we're likely to get a coredump due to a segfault in new_threadstate. At the point of the core dump, the gdb main thread looks like: ... (gdb) bt #0 0x0000fffee30d2280 in __pthread_kill_implementation () from /lib64/libc.so.6 #1 0x0000fffee3085800 [PAC] in raise () from /lib64/libc.so.6 #2 0x00000000007b03e8 [PAC] in handle_fatal_signal (sig=11) at gdb/event-top.c:926 #3 0x00000000007b0470 in handle_sigsegv (sig=11) at gdb/event-top.c:976 #4 #5 0x0000fffee3a4db14 in new_threadstate () from /lib64/libpython3.12.so.1.0 #6 0x0000fffee3ab0548 [PAC] in PyGILState_Ensure () from /lib64/libpython3.12.so.1.0 #7 0x0000000000a6d034 [PAC] in gdbpy_gil::gdbpy_gil (this=0xffffcb279738) at gdb/python/python-internal.h:787 #8 0x0000000000ab87ac in gdbpy_event::~gdbpy_event (this=0xfffea8001ee0, __in_chrg=) at gdb/python/python.c:1051 #9 0x0000000000ab9460 in std::_Function_base::_Base_manager<...>::_M_destroy (__victim=...) at /usr/include/c++/13/bits/std_function.h:175 #10 0x0000000000ab92dc in std::_Function_base::_Base_manager<...>::_M_manager (__dest=..., __source=..., __op=std::__destroy_functor) at /usr/include/c++/13/bits/std_function.h:203 #11 0x0000000000ab8f14 in std::_Function_handler<...>::_M_manager(...) (...) at /usr/include/c++/13/bits/std_function.h:282 #12 0x000000000042dd9c in std::_Function_base::~_Function_base (this=0xfffea8001c10, __in_chrg=) at /usr/include/c++/13/bits/std_function.h:244 #13 0x000000000042e654 in std::function::~function() (this=0xfffea8001c10, __in_chrg=) at /usr/include/c++/13/bits/std_function.h:334 #14 0x0000000000b68e60 in std::_Destroy >(...) (...) at /usr/include/c++/13/bits/stl_construct.h:151 #15 0x0000000000b68cd0 in std::_Destroy_aux::__destroy<...>(...) (...) at /usr/include/c++/13/bits/stl_construct.h:163 #16 0x0000000000b689d8 in std::_Destroy<...>(...) (...) at /usr/include/c++/13/bits/stl_construct.h:196 #17 0x0000000000b68414 in std::_Destroy<...>(...) (...) at /usr/include/c++/13/bits/alloc_traits.h:948 #18 std::vector<...>::~vector() (this=0x2a183c8 ) at /usr/include/c++/13/bits/stl_vector.h:732 #19 0x0000fffee3088370 in __run_exit_handlers () from /lib64/libc.so.6 #20 0x0000fffee3088450 [PAC] in exit () from /lib64/libc.so.6 #21 0x0000000000c95600 [PAC] in quit_force (exit_arg=0x0, from_tty=0) at gdb/top.c:1822 #22 0x0000000000609140 in quit_command (args=0x0, from_tty=0) at gdb/cli/cli-cmds.c:508 #23 0x0000000000c926a4 in quit_cover () at gdb/top.c:300 #24 0x00000000007b09d4 in async_disconnect (arg=0x0) at gdb/event-top.c:1230 #25 0x0000000000548acc in invoke_async_signal_handlers () at gdb/async-event.c:234 #26 0x000000000157d2d4 in gdb_do_one_event (mstimeout=-1) at gdbsupport/event-loop.cc:199 #27 0x0000000000943a84 in start_event_loop () at gdb/main.c:401 #28 0x0000000000943bfc in captured_command_loop () at gdb/main.c:465 #29 0x000000000094567c in captured_main (data=0xffffcb279d08) at gdb/main.c:1335 #30 0x0000000000945700 in gdb_main (args=0xffffcb279d08) at gdb/main.c:1354 #31 0x0000000000423ab4 in main (argc=14, argv=0xffffcb279e98) at gdb/gdb.c:39 ... The direct cause of the segfault is calling PyGILState_Ensure after calling Py_Finalize. AFAICT the problem is a race between the gdb main thread and DAP's JSON writer thread. On one side, we have the following events: - DAP's JSON reader thread reads an EOF - it lets DAP's JSON writer thread known by writing None into its queue - DAP's JSON writer thread sees the None in its queue, and calls send_gdb("quit") - a corresponding gdbpy_event is deposited in the runnables vector, to be run by the gdb main thread On the other side, we have the following events: - the gdb main thread receives a SIGHUP - the corresponding handler calls quit_force, which calls do_final_cleanups - one of the final cleanups is finalize_python, which calls Py_Finalize - quit_force calls exit, which triggers the exit handlers - one of the exit handlers is the destructor of the runnables vector - destruction of the vector triggers destruction of the remaining element - the remaining element is a gdbpy_event, and the destructor (indirectly) calls PyGILState_Ensure My first attempt at fixing this was to write a finalize_runnables and call it from quit_force, similar to finalize_values, to ensure that the gdbpy_event destructor is called before Py_Finalize. However, I still ran into the same problem due to the gdbpy_event being posted after finalize_runnables was called. I managed to handle this by ignoring run_on_main_thread after finalize_runnables, but it made me wonder if there's a better way. Then I tried to simply remove send_gdb("quit"), and that worked as well, and caused no regressions. So, either this is the easiest way to address this, or we need to add a test-case that regresses when we remove it. This RFC uses the latter approach. Perhaps the former is better, perhaps something else is needed, I'm not sure. Tested on aarch64-linux. PR dap/31306 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31306 --- gdb/python/lib/gdb/dap/io.py | 1 - 1 file changed, 1 deletion(-) diff --git a/gdb/python/lib/gdb/dap/io.py b/gdb/python/lib/gdb/dap/io.py index 5149edae977..4edd504c727 100644 --- a/gdb/python/lib/gdb/dap/io.py +++ b/gdb/python/lib/gdb/dap/io.py @@ -68,7 +68,6 @@ def start_json_writer(stream, queue): # This is an exit request. The stream is already # flushed, so all that's left to do is request an # exit. - send_gdb("quit") break obj["seq"] = seq seq = seq + 1 -- 2.35.3