From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 6cCaKmN/F2mDKgIAWB0awg (envelope-from ) for ; Fri, 14 Nov 2025 14:13:39 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=dCDmzBXF; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id AAADC1E0B8; Fri, 14 Nov 2025 14:13:39 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 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_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED 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 3151F1E04C for ; Fri, 14 Nov 2025 14:13:39 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DD0563858D33 for ; Fri, 14 Nov 2025 19:13:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DD0563858D33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1763147618; bh=Z0768c6vZQW3X1j+VL11s1v8bPRB8hi3zDIAnzoasDE=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=dCDmzBXFN0waNUMwaHqES01eUKfwPyIk2aCX0xZhaxDrvrDlpnTSLoiAcq3ItLWHZ W6Hlx3pTtXCVDfeZEJV0op8Gon/BpwWpixcLBh1RCofqHqQzJRaEJ6N9fpz4ImIE+l 9u+b/My4UYjLO1T7EaT/mS6KYlmVzJrkbUhEAP84= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 8F39A3858D20 for ; Fri, 14 Nov 2025 19:12:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8F39A3858D20 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8F39A3858D20 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1763147571; cv=none; b=jgv+A/ovrpNS4YUXyjoWGU+vw7BfaN5wuphAydXBWa4/2bptiK6BK4G8nthcAbH6wF3IUX+9vhhMYI5j/Mg25GDIJ5OqjiAc/PjOwaNHkPbBPklC+75l7dZlFrL7OkNmQaYBBcHIAxdh983zbe5e5GkGxwC6Nd8Rya4nWhzbaWk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1763147571; c=relaxed/simple; bh=51TQyd+fAqFQyjS+qduyp3b/6gnPQMBM7lyZMrzvOVE=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=eX5YYUMCuX5M0Vo7zjSileBtovSiP5LNA0s9wOLYU5ne+vGEQpdMTfOSH2h/FpNlcdqk8KCk4Fi42tJz+SRPyKDWrjaZUd+1mqYbNiZgpwPOnpFcZIaRDIwwQqjLxGvjZlQHBcH0OQDY6Wo5ci5FCWxSwzfGfnlgBAnSUHNplyY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8F39A3858D20 Received: by simark.ca (Postfix) id B2B981E04C; Fri, 14 Nov 2025 14:12:50 -0500 (EST) Message-ID: <8aaf2a81-b4a5-4314-a0fb-e090b136bd34@simark.ca> Date: Fri, 14 Nov 2025 14:12:49 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: GDB 15/16 crashing in add_thread_silent() To: psmith@gnu.org, gdb@sourceware.org References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb Reply-To: Simon Marchi Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 2025-11-14 13:56, Paul Smith via Gdb wrote: > Hi all; > > I have a core file generated from my C++ program (running on GNU/Linux > x86_64, built with GCC 14.2). When I try to open this core file with > either GDB 15.2 or GDB 16.3 (also built by me, on GNU/Linux x86_64 with > GCC 14.2), GDB itself will crash. > > I tried opening this core with GDB 8.2 built from the Red Hat source > package, provided by Rocky Linux 8.10, and this was able to open the > core (but it doesn't have other facilities I need). > > > I rebuilt GDB 16.3 with -ggdb3 -O0 and here's the backtrace (I elided > some of the paths etc.): > > #2 0x0000000000fd266e in handle_sigsegv (sig=11) at gdb/event-top.c:1089 > #3 > #4 0x0000000001079a1a in std::_Hashtable,...>::size (this=0x28) > at /cc/unknown/x86_64-unknown-linux-gnu/include/c++/14.2.0/bits/hashtable.h:657 > #5 0x0000000001078df0 in std::_Hashtable,...>::find (this=0x28, > __k=...) > at /cc/unknown/x86_64-unknown-linux-gnu/include/c++/14.2.0/bits/hashtable.h:1728 > #6 0x0000000001077cba in std::unordered_map,...>::find (this=0x28, __x=...) > at /cc/unknown/x86_64-unknown-linux-gnu/include/c++/14.2.0/bits/unordered_map.h:877 > #7 0x0000000001073469 in inferior::find_thread (this=0x0, ptid=...) > at gdb/inferior.c:251 > #8 0x00000000013817cd in add_thread_silent (targ=0x3ed1ae0, ptid=...) > at gdb/thread.c:311 > #9 0x0000000000e7e877 in core_target_open ( > arg=0x7fb308098fc0 "core.9168", from_tty=1) at gdb/corelow.c:1123 > #10 0x0000000000e7d210 in core_file_command ( > filename=0x7fb308098fc0 "core.9168", from_tty=1) at gdb/corelow.c:724 > #11 0x0000000001113774 in catch_command_errors ( > command=0xe7d14f , > arg=0x7fb308098fc0 "core.9168", from_tty=1, do_bp_actions=false) at gdb/main.c:508 > #12 0x0000000001114c5b in captured_main_1 (context=0x7fff0e4eccd0) > at gdb/main.c:1238 > #13 0x00000000011152e4 in captured_main (data=0x7fff0e4eccd0) > at gdb/main.c:1333 > #14 0x0000000001115384 in gdb_main (args=0x7fff0e4eccd0) at gdb/main.c:1362 > #15 0x0000000000c90cf6 in main (argc=19, argv=0x7fff0e4ecdc8) at gdb/gdb.c:38 > > > > Looks like add_thread_silent() is looking up the inferior with > find_inferior_ptid() and that doesn't find anything (returns nullptr), > which is then not checked before we try to find the current thread: > > thread_info *tp = inf->find_thread (ptid); > > The latest Git HEAD code still seems to be missing this nullptr check. > > Of course, the real question is why we can't find the inferior ptid. I > have no idea about that. The normal path is: - the call to inferior_appeared, in core_target_open, sets the pid of the current inferior - normally, the subsequent calls to add_to_thread_list add threads with the correct ptid::pid: ptid_t ptid (inf->pid, lwpid); thread_info *thr = add_thread (inf->process_target (), ptid); - however, you hit the add_thread_silent call at line corelow.c:1123: if (inferior_ptid == null_ptid) { /* Either we found no .reg/NN section, and hence we have a non-threaded core (single-threaded, from gdb's perspective), or for some reason add_to_thread_list couldn't determine which was the "main" thread. The latter case shouldn't usually happen, but we're dealing with input here, which can always be broken in different ways. */ thread_info *thread = first_thread_of_inferior (inf); if (thread == NULL) here >>> thread = add_thread_silent (target, ptid_t (CORELOW_PID)); switch_to_thread (thread); } Where CORELOW_PID is: /* An arbitrary identifier for the core inferior. */ #define CORELOW_PID 1 This tries to add a thread with ptid(1, 0, 0). And there is not inferior with pid 1, which is probably the reason for what you see. That line appears to be a fallback to at least have a thread, if we weren't able to create threads from the notes section in the core. But I guess it's not exercised at all by the testsuite. And it's not clear what we should do in that situation. That is the most I can tell you without being able to look at the actual core. Simon