From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id OzXTOI17F2mPHgIAWB0awg (envelope-from ) for ; Fri, 14 Nov 2025 13:57:17 -0500 Received: by simark.ca (Postfix, from userid 112) id D76CC1E0B8; Fri, 14 Nov 2025 13:57:17 -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.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, 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 531D21E04C for ; Fri, 14 Nov 2025 13:57:17 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B07143858C53 for ; Fri, 14 Nov 2025 18:57:10 +0000 (GMT) Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id C8D273858D20 for ; Fri, 14 Nov 2025 18:56:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C8D273858D20 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C8D273858D20 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1763146603; cv=none; b=bsJ9/n+onnA0ahX0VWyhM2BFblqGSRSWLOW8PARdiVLgq57MvxIJXK+XCEvuAFHaaXrog4FXI/pyNYhIEXuKZwQx0+iRKuVn91irfJf+0qvK7T41T/4W5sg63qsvv8sDw+zxEHtcEollsLPjUYppcC+GUDhw6TTfbbJqJURXfnU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1763146603; c=relaxed/simple; bh=nSKsclalgFKVZ5C8qfU679nDkCiiBbH3vSPgfouwsCw=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=oyCtItam/gSfXyvD6GWNd3auSDzp/WaUz6SNDXQl1sp9bcqmdCNDQOWUa6twbJiAZlzlZw2VKIbdKmPjk6GTja5AliEvy91yP7wNjmTbZSrhMSja8lnGt7mge19ejTsofN5zKN+jzVRrvFOhgmgGo1VFIAPFbx0LMCC9/nXPs+g= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C8D273858D20 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1vJyyL-0000cB-16 for gdb@sourceware.org; Fri, 14 Nov 2025 13:56:37 -0500 Message-ID: Subject: GDB 15/16 crashing in add_thread_silent() To: gdb@sourceware.org Date: Fri, 14 Nov 2025 13:56:14 -0500 Organization: GNU's Not UNIX! Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.1 (by Flathub.org) MIME-Version: 1.0 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: Paul Smith via Gdb Reply-To: psmith@gnu.org Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" 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=3D11) at gdb/event-top.c:1089 #3 #4 0x0000000001079a1a in std::_Hashtable,...>::size (this=3D0x28) at /cc/unknown/x86_64-unknown-linux-gnu/include/c++/14.2.0/bits/hashtab= le.h:657 #5 0x0000000001078df0 in std::_Hashtable,...>::find (this=3D0x28, __k=3D...) at /cc/unknown/x86_64-unknown-linux-gnu/include/c++/14.2.0/bits/hashtab= le.h:1728 #6 0x0000000001077cba in std::unordered_map,...>::find (this=3D0x28, __x=3D...) at /cc/unknown/x86_64-unknown-linux-gnu/include/c++/14.2.0/bits/unorder= ed_map.h:877 #7 0x0000000001073469 in inferior::find_thread (this=3D0x0, ptid=3D...) at gdb/inferior.c:251 #8 0x00000000013817cd in add_thread_silent (targ=3D0x3ed1ae0, ptid=3D...) at gdb/thread.c:311 #9 0x0000000000e7e877 in core_target_open ( arg=3D0x7fb308098fc0 "core.9168", from_tty=3D1) at gdb/corelow.c:1123 #10 0x0000000000e7d210 in core_file_command ( filename=3D0x7fb308098fc0 "core.9168", from_tty=3D1) at gdb/corelow.c:7= 24 #11 0x0000000001113774 in catch_command_errors ( command=3D0xe7d14f , arg=3D0x7fb308098fc0 "core.9168", from_tty=3D1, do_bp_actions=3Dfalse) = at gdb/main.c:508 #12 0x0000000001114c5b in captured_main_1 (context=3D0x7fff0e4eccd0) at gdb/main.c:1238 #13 0x00000000011152e4 in captured_main (data=3D0x7fff0e4eccd0) at gdb/main.c:1333 #14 0x0000000001115384 in gdb_main (args=3D0x7fff0e4eccd0) at gdb/main.c:13= 62 #15 0x0000000000c90cf6 in main (argc=3D19, argv=3D0x7fff0e4ecdc8) at gdb/gd= b.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 =3D 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.