From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 2eu8KTaBF2nVLwIAWB0awg (envelope-from ) for ; Fri, 14 Nov 2025 14:21:26 -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=Y6jWhdGi; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 888EC1E0B8; Fri, 14 Nov 2025 14:21:26 -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 A120C1E04C for ; Fri, 14 Nov 2025 14:21:25 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2F8ED3858D20 for ; Fri, 14 Nov 2025 19:21:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2F8ED3858D20 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1763148085; bh=KBq1FIqs/sYPODicqVzeII+mU2BKHkPV55npKDb7OIs=; h=Subject:To:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=Y6jWhdGiANjDhK17gR+wMcCItM8+J94Im51RzireOprlwxLU7Pf3rr8uTkS4EIfaY HUrE08G5+5FyONdE044+Ad1Xx1W106W1YZxZZJoibD8Wkz+NrmSfJHpybDwLoDTO3k iwKaRlFhVS06IkPJWlpyOKECg+DakLkGiAKct0To= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id B23B73858D20 for ; Fri, 14 Nov 2025 19:20:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B23B73858D20 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B23B73858D20 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1763148031; cv=none; b=oxHU28rE/Y2EVdjFu14F1/YGS/gh5rGuvqv+0E3H2aGuQkURyuARo1lCcSW0A98BC7uZN9EvE/PftQ+I/OCtTVi9jTtvzVLQf83TYL64fydqj6Yx3iioJr/P2rAM1buIyhKKq0oZ7siTHPL4Kos4s2HyjqDLAp7PTZJ5Ea9sep8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1763148031; c=relaxed/simple; bh=7l3Fg9qwl5xYsgG0V7dyqBDBT1xdfws5S2m4Z+rWUOA=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=I2JMd1BGJRNeoSF+wQ1W7nEBmVptgwO3ddnIt0nbj0jcIKnJcWtsIjJfxhvjojHw/RwkZvEeDWjZhJnpPB/I8mDb0wA0klQAZhSiVnZfB6YDuHkENUiY2vsVDLnVqeFLBaa9xshW2148+aRBFtmamhrE1QV4ctwHbcqvWbpGrDM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B23B73858D20 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 1vJzLT-0007Lv-Bc for gdb@sourceware.org; Fri, 14 Nov 2025 14:20:31 -0500 Message-ID: <78bf54fc9dfbb57d3434d8435e94b091e1fa6785.camel@gnu.org> Subject: Re: GDB 15/16 crashing in add_thread_silent() To: gdb@sourceware.org Date: Fri, 14 Nov 2025 14:20:28 -0500 In-Reply-To: References: 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" I investigated more and the problem is that GDB cannot determine the PID of the core file. I checked the inferiors list and it looks correct, but the ptid value passed into add_thread_silent() has a bad PID: (gdb) fr 8 #8 0x00000000013817cd in add_thread_silent (targ=3D0x3ed1ae0, ptid=3D...) at gdb/thread.c:311 warning: 311 gdb/thread.c: No such file or directory (gdb) p ptid $6 =3D { m_pid =3D 1, m_lwp =3D 0, m_tid =3D 0 } This is apparently because we entered this code in corelow.c: if (inferior_ptid =3D=3D 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 =3D first_thread_of_inferior (inf); if (thread =3D=3D NULL) thread =3D add_thread_silent (target, ptid_t (CORELOW_PID)); switch_to_thread (thread); } It appears that add_thread_silent() doesn't work properly with CORELOW_PID (1). Just to note, my program is decidedly NOT single-threaded; there are 20+ active threads in it. I see that this (still in corelow.c:core_target_open()) returns the correct PID: int pid =3D bfd_core_file_pid (current_program_space->core_bfd ()); so I think it's a bug that when we invoke add_thread_silent() above we use CORELOW_PID instead of just pid. On Fri, 2025-11-14 at 13:56 -0500, Paul Smith via Gdb wrote: > Hi all; >=20 > I have a core file generated from my C++ program (running on > GNU/Linux > x86_64, built with GCC 14.2).=C2=A0 When I try to open this core file wit= h > 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. >=20 > 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). >=20 >=20 > I rebuilt GDB 16.3 with -ggdb3 -O0 and here's the backtrace (I elided > some of the paths etc.): >=20 > #2=C2=A0 0x0000000000fd266e in handle_sigsegv (sig=3D11) at gdb/event- > top.c:1089 > #3=C2=A0 > #4=C2=A0 0x0000000001079a1a in std::_Hashtable const, thread_info*>,...>::size (this=3D0x28) > =C2=A0=C2=A0=C2=A0 at /cc/unknown/x86_64-unknown-linux- > gnu/include/c++/14.2.0/bits/hashtable.h:657 > #5=C2=A0 0x0000000001078df0 in std::_Hashtable const, thread_info*>,...>::find (this=3D0x28, > =C2=A0=C2=A0=C2=A0 __k=3D...) > =C2=A0=C2=A0=C2=A0 at /cc/unknown/x86_64-unknown-linux- > gnu/include/c++/14.2.0/bits/hashtable.h:1728 > #6=C2=A0 0x0000000001077cba in std::unordered_map std::hash,...>::find (this=3D0x28, __x=3D...) > =C2=A0=C2=A0=C2=A0 at /cc/unknown/x86_64-unknown-linux- > gnu/include/c++/14.2.0/bits/unordered_map.h:877 > #7=C2=A0 0x0000000001073469 in inferior::find_thread (this=3D0x0, ptid=3D= ...) > =C2=A0=C2=A0=C2=A0 at gdb/inferior.c:251 > #8=C2=A0 0x00000000013817cd in add_thread_silent (targ=3D0x3ed1ae0, > ptid=3D...) > =C2=A0=C2=A0=C2=A0 at gdb/thread.c:311 > #9=C2=A0 0x0000000000e7e877 in core_target_open ( > =C2=A0=C2=A0=C2=A0 arg=3D0x7fb308098fc0 "core.9168", from_tty=3D1) at gdb= /corelow.c:1123 > #10 0x0000000000e7d210 in core_file_command ( > =C2=A0=C2=A0=C2=A0 filename=3D0x7fb308098fc0 "core.9168", from_tty=3D1) a= t > gdb/corelow.c:724 > #11 0x0000000001113774 in catch_command_errors ( > =C2=A0=C2=A0=C2=A0 command=3D0xe7d14f , > =C2=A0=C2=A0=C2=A0 arg=3D0x7fb308098fc0 "core.9168", from_tty=3D1, do_bp_= actions=3Dfalse) > at gdb/main.c:508 > #12 0x0000000001114c5b in captured_main_1 (context=3D0x7fff0e4eccd0) > =C2=A0=C2=A0=C2=A0 at gdb/main.c:1238 > #13 0x00000000011152e4 in captured_main (data=3D0x7fff0e4eccd0) > =C2=A0=C2=A0=C2=A0 at gdb/main.c:1333 > #14 0x0000000001115384 in gdb_main (args=3D0x7fff0e4eccd0) at > gdb/main.c:1362 > #15 0x0000000000c90cf6 in main (argc=3D19, argv=3D0x7fff0e4ecdc8) at > gdb/gdb.c:38 >=20 >=20 >=20 > 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: >=20 > =C2=A0 thread_info *tp =3D inf->find_thread (ptid); >=20 > The latest Git HEAD code still seems to be missing this nullptr > check. >=20 > Of course, the real question is why we can't find the inferior ptid.=C2= =A0 > I > have no idea about that.