Re: GDB 15/16 crashing in add_thread_silent()

[Paul Smith via Gdb <gdb@sourceware.org>]

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=0x3ed1ae0, ptid=...)
    at gdb/thread.c:311
warning: 311    gdb/thread.c: No such file or directory
(gdb) p ptid
$6 = {
  m_pid = 1,
  m_lwp = 0,
  m_tid = 0
}

This is apparently because we entered this code in corelow.c:

   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)
         thread = 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 = 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;
> 
> 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  <signal handler called>
> #4  0x0000000001079a1a in std::_Hashtable<ptid_t, std::pair<ptid_t
> const, thread_info*>,...>::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<ptid_t, std::pair<ptid_t
> const, thread_info*>,...>::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<ptid_t, thread_info*,
> std::hash<ptid_t>,...>::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 <core_file_command(char const*, int)>,
>     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.