Re: GDB 15/16 crashing in add_thread_silent()

[Simon Marchi via Gdb <gdb@sourceware.org>]

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  <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.

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