From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 67DDD3858D32 for ; Tue, 14 Nov 2023 15:09:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 67DDD3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 67DDD3858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699974583; cv=none; b=b9pLmWdg7XAFrvUu0UGEZlRR/NJl2th6ljCQG3dJxvfyfX9DgWgwsCtEaS1FPfFA/Mp/pH7e7g2i9xv00NBitOIiES3BEBBYSpNqnJZRTRdAkDwF1NGhQJk9hyJMOQ8iwRPV942PluK973dDiAYhpT9y4foN+2KhG/XWIcd6rl4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699974583; c=relaxed/simple; bh=iyzWpTeTlWM+PJRM1Sl1ofhtHsn4xOB2NMirWQrvpAs=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=xg0PaexWOV41f0i2LKZ1HXsGAPFOr47qME4F8+eduFo8DwQr+A2UgvJb3GIflwu4sbz2HxU4tzLbbFT19m/jJ1DAOYDxqhNj2lvnXFUteosY24oXEJj6Czam3aD9ohE6H2ZnwJ63UcvnUUfIDBjHSAuz+IcRxDPGM1UioFMR7gQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1699974582; bh=iyzWpTeTlWM+PJRM1Sl1ofhtHsn4xOB2NMirWQrvpAs=; h=Date:Subject:To:References:From:In-Reply-To:From; b=Lu0jJJ8HXaZBjO8UGsr8REQDryt6ZxQKSapkJUiJV3kpyyYK5zpmuW9JFAVCR7JoL jc4OsnkFzCk3C9+RgisCvs3ri3CBLOO7rzG3f2CkpL9a/bcrtTz6onVRAKWNqj9IjM uH53J9Z7GPF0EkpnD365gGutNOr7EL0KtYRB9Wzs= Received: from [172.25.82.120] (unknown [12.186.190.2]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 1AF921E091; Tue, 14 Nov 2023 10:09:41 -0500 (EST) Message-ID: <601592c1-4e19-42c8-bfd7-5671ef951ab3@simark.ca> Date: Tue, 14 Nov 2023 10:09:41 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] [gdb] Fix assert in delete_breakpoint Content-Language: fr To: Tom de Vries , gdb-patches@sourceware.org References: <20231113152609.32726-1-tdevries@suse.de> From: Simon Marchi In-Reply-To: <20231113152609.32726-1-tdevries@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: On 11/13/23 10:26, Tom de Vries wrote: > On a pinebook (aarch64 with 64-bit kernel and 32-bit userland) with test-case > gdb.base/gdb-sigterm.exp I run into: > ... > intrusive_list.h:458: internal-error: erase_element: \ > Assertion `elem_node->prev != INTRUSIVE_LIST_UNLINKED_VALUE' failed.^M > ... > > Fix this similar to: > - commit c0afd99439f ("[gdb/tui] Fix assert in ~gdbpy_tui_window_maker"), and > - commit 995a34b1772 ("Guard against frame.c destructors running before > frame-info.c's" > by checking is_linked () before attempting to remove from breakpoint_chain. > > Tested on the pinebook and x86_64-linux. > > PR gdb/31061 > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31061 Hi Tom, Did you dig a little bit to understand why this happened specifically with this setup, and that it's indeed expected that the breakpoint is not in the breakpoint chain? The stack trace you showed contains (with names demangled): 0xaae1d42b delete_breakpoint(breakpoint*)^M /home/rock/gdb/src/gdb/breakpoint.c:12636^M 0xab1ed045 delete_thread_breakpoint^M /home/rock/gdb/src/gdb/thread.c:98^M 0xab1ed0ab delete_single_step_breakpoints(thread_info*)^M /home/rock/gdb/src/gdb/thread.c:123^M 0xab021e81 delete_thread_infrun_breakpoints^M /home/rock/gdb/src/gdb/infrun.c:3733^M 0xab021edd for_each_just_stopped_thread^M /home/rock/gdb/src/gdb/infrun.c:3752^M 0xab021f79 delete_just_stopped_threads_infrun_breakpoints^M /home/rock/gdb/src/gdb/infrun.c:3768^M It looks like this is specific to architectures that use software single stepping? Does "32-bit userland on 64-bit kernel on aarch64" use software single stepping, like 32-bit ARM? Software single step breakpoints are inserted with: if (tp->control.single_step_breakpoints == NULL) { std::unique_ptr b (new momentary_breakpoint (gdbarch, bp_single_step, current_program_space, null_frame_id, tp->global_num)); tp->control.single_step_breakpoints = add_to_breakpoint_chain (std::move (b)); } They are added to the global breakpoint_chain by add_to_breakpoint_chain. So how come the breakpoint is not linked when comes the time to delete it? Simon