Re: GDB 15/16 crashing in add_thread_silent()

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

On Fri, 2025-11-14 at 13:13 -0700, Tom Tromey wrote:
> > > > > > "Simon" == Simon Marchi via Gdb <gdb@sourceware.org>
> > > > > > writes:
> 
> > > Earlier if the PID couldn't be found then pid is set to
> > > CORELOW_PID anyway, so this works and prevents the crash
> > > (although, I think GDB should check for the nullptr return and do
> > > _something_ non-crashy... maybe?)
> 
> See this thread as well
> 
> https://inbox.sourceware.org/gdb-patches/20251024124208.1875651-1-
> tdevries@suse.de/
> 
> I wonder if the fix (assuming it arrives) should be in GDB 17.

Tom suggested exactly the same fix I did (although, in addition,
thread.c:add_thread_silent():

   inferior *inf = find_inferior_ptid (targ, ptid);

should be handling nullptr return somehow, I should think).


Anyway, Tom de Vries writes this in summary:

> I suppose this is fixable, but I'm not sure it's worth the effort for
> a core file that has such limited usability.

I don't know about his core, but my coredump definitely doesn't have
limited usability, because when I use GDB 8.2 from Rocky Linux the core
is fully usable in all respects: I can see all the threads and interact
with them in all ways.

The downside for me is that I have a lot of Python macros that I need
to work with my core files, and they don't work with the very old GDB
8.2, for various reasons.

What we need to understand is why this much older GDB can work
correctly with the core file, but newer GDB can't find basic things.