[PATCH] [gdb/corefiles] Fix segfault in add_thread_silent

[PATCH] [gdb/corefiles] Fix segfault in add_thread_silent

[Tom de Vries]

A user reported a segfault when loading a core file [1].

The core file is from arm-linux, but I reproduced the segfault on
x86_64-linux:
...
$ gdb -q --core core

warning: Can't open file /usr/bin/rs_scope during file-backed mapping note processing

warning: Can't open file /lib/libc-2.26.so during file-backed mapping note processing

warning: File /lib/libgcc_s.so.1 doesn't match build-id from core-file during file-backed mapping processing

warning: Can't open file /lib/libm-2.26.so during file-backed mapping note processing

warning: Can't open file /usr/lib/libstdc++.so.6.0.28 during file-backed mapping note processing

warning: Can't open file /lib/libpthread-2.26.so during file-backed mapping note processing

warning: Can't open file /lib/ld-2.26.so during file-backed mapping note processing

Fatal signal: Segmentation fault
----- Backtrace -----
0x64a4ff gdb_internal_backtrace_1
	gdb/bt-utils.c:122
0x64a59d _Z22gdb_internal_backtracev
	gdb/bt-utils.c:175
0x9429e7 handle_fatal_signal
	gdb/event-top.c:1013
0x942b96 handle_sigsegv
	gdb/event-top.c:1090
0x7fbf6a64708f ???
	/usr/src/debug/glibc-2.40/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x5eb453 _ZN9__gnu_cxx17__normal_iteratorIPKSt4pairI6ptid_tP11thread_infoESt6vectorIS5_SaIS5_EEEC4ERKS7_
	/usr/include/c++/15/bits/stl_iterator.h:1059
0x5eb453 _ZNKSt6vectorISt4pairI6ptid_tP11thread_infoESaIS4_EE3endEv
	/usr/include/c++/15/bits/stl_vector.h:1029
0x5eae9e _ZNKSt6vectorISt4pairI6ptid_tP11thread_infoESaIS4_EE5emptyEv
	/usr/include/c++/15/bits/stl_vector.h:1224
0xa77588 _ZNK6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE5emptyEv
	gdb/../gdbsupport/unordered_dense.h:1351
0xa76533 _ZN6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE7do_findIS4_EEN9__gnu_cxx17__normal_iteratorIPSC_St6vectorISC_SD_EEERKT_
	gdb/../gdbsupport/unordered_dense.h:1119
0xa74fef _ZN6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE4findERKS4_
	gdb/../gdbsupport/unordered_dense.h:1773
0xa6f787 _ZN8inferior11find_threadE6ptid_t
	gdb/inferior.c:253
0xfc852a _Z17add_thread_silentP22process_stratum_target6ptid_t
	gdb/thread.c:310
0x73b995 core_target_open
	gdb/corelow.c:1111
0x73a095 _Z17core_file_commandPKci
	gdb/corelow.c:708
0xb6cb38 catch_command_errors
	gdb/main.c:510
0xb6e354 captured_main_1
	gdb/main.c:1279
0xb6e9a2 captured_main
	gdb/main.c:1372
0xb6eaa3 _Z8gdb_mainP18captured_main_args
	gdb/main.c:1401
0x419704 main
	gdb/gdb.c:38
...

The problem happens as follows.  In core_target_open, we do:
...
      if (thread == NULL)
        thread = add_thread_silent (target, ptid_t (CORELOW_PID));
...
and then in add_thread_silent:
...
struct thread_info *
add_thread_silent (process_stratum_target *targ, ptid_t ptid)
{
  gdb_assert (targ != nullptr);

  inferior *inf = find_inferior_ptid (targ, ptid);
...
find_inferior_ptid returns nullptr, which eventually causes the segfault.

So, why can't we find an inferior with CORELOW_PID?

A bit earlier in core_target_open, we do:
...
  /* Find (or fake) the pid for the process in this core file, and
     initialise the current inferior with that pid.  */
  bool fake_pid_p = false;
  int pid = bfd_core_file_pid (target->core_bfd ());
  if (pid == 0)
    {
      fake_pid_p = true;
      pid = CORELOW_PID;
    }

  inferior *inf = current_inferior ();
  gdb_assert (inf->pid == 0);
  inferior_appeared (inf, pid);
  inf->fake_pid_p = fake_pid_p;
...

The problem is that looking for an inferior using CORELOW_PID is correct in
case fake_pid_p == true, but otherwise not.

Fix this by using inf->pid instead:
...
-	thread = add_thread_silent (target, ptid_t (CORELOW_PID));
+	thread = add_thread_silent (target, ptid_t (inf->pid));
...

Doing so enables us to continue to a gdb prompt:
...
Core was generated by `/usr/bin/rs_scope -d'.

⚠️ warning: Couldn't find general-purpose registers in core file.
(gdb)
...

The warning seem correct.  Looking at the core file:
...
$ objdump -h core

core:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 note0         00000efc  00000000  00000000  000006f4  2**0
                  CONTENTS, READONLY
  1 .note.linuxcore.siginfo/1037 00000080  00000000  00000000  00000848  2**2
                  CONTENTS
  2 .note.linuxcore.siginfo 00000080  00000000  00000000  00000848  2**2
                  CONTENTS
  3 .auxv         000000a0  00000000  00000000  000008dc  2**2
                  CONTENTS
  4 .note.linuxcore.file/1037 000003ce  00000000  00000000  00000990  2**2
                  CONTENTS
  5 .note.linuxcore.file 000003ce  00000000  00000000  00000990  2**2
                  CONTENTS
  6 .reg2/1037    00000074  00000000  00000000  00000d74  2**2
                  CONTENTS
  7 .reg2         00000074  00000000  00000000  00000d74  2**2
                  CONTENTS
  8 .reg-arm-vfp/1037 00000104  00000000  00000000  00000dfc  2**2
                  CONTENTS
  9 .reg-arm-vfp  00000104  00000000  00000000  00000dfc  2**2
                  CONTENTS
 10 .reg2/1037    00000074  00000000  00000000  00000fc4  2**2
                  CONTENTS
 11 .reg-arm-vfp/1037 00000104  00000000  00000000  0000104c  2**2
                  CONTENTS
 12 .reg2/1037    00000074  00000000  00000000  00001214  2**2
                  CONTENTS
 13 .reg-arm-vfp/1037 00000104  00000000  00000000  0000129c  2**2
                  CONTENTS
 14 .reg2/1037    00000074  00000000  00000000  00001464  2**2
                  CONTENTS
 15 .reg-arm-vfp/1037 00000104  00000000  00000000  000014ec  2**2
                  CONTENTS
...
indeed there's no .reg section containing the general-purpose registers.

Also, the presence of both .reg2 and .reg-arm-vfp seems odd.  At least
arm_linux_iterate_over_regset_sections thinks that a core file should have one
or the other but not both.

So, my guess would be that there's some kernel bug that writes .reg2 instead
of .reg in the core file.

I also wondered if it could be a naming problem, but the size of .reg2 is
appropriate for .reg2 (0x74), not for .reg (0x48).

Having no general-purpose registers, there's not much we can do with the core
file, for instance we can't get a backtrace:
...
(gdb) bt
Python Exception <class 'gdb.error'>: Register 13 is not available
(gdb)
...

We can print a .reg-arm-vfp register:
...
(gdb) p /x $d0
$1 = 0x43444949202d2074
...
but that highlights the next problem.

There's only one thread:
...
(gdb) info threads
  Id   Target Id         Frame
* 1    process 1037      <unavailable> in ?? ()
(gdb)
...
while the core file seems to contain 4 of them:
...
$ objdump -h core | grep .reg-arm-vfp
  8 .reg-arm-vfp/1037 00000104  00000000  00000000  00000dfc  2**2
  9 .reg-arm-vfp  00000104  00000000  00000000  00000dfc  2**2
 11 .reg-arm-vfp/1037 00000104  00000000  00000000  0000104c  2**2
 13 .reg-arm-vfp/1037 00000104  00000000  00000000  0000129c  2**2
 15 .reg-arm-vfp/1037 00000104  00000000  00000000  000014ec  2**2
...

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

Tested on x86_64-linux.

PR corefiles/33560
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33560

[1] https://bugzilla.suse.com/show_bug.cgi?id=1251213
---
 gdb/corelow.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/corelow.c b/gdb/corelow.c
index 218504bcdc8..37f38d99815 100644
--- a/gdb/corelow.c
+++ b/gdb/corelow.c
@@ -1108,7 +1108,7 @@ core_target_open (const char *arg, int from_tty)
       thread_info *thread = first_thread_of_inferior (inf);
 
       if (thread == NULL)
-	thread = add_thread_silent (target, ptid_t (CORELOW_PID));
+	thread = add_thread_silent (target, ptid_t (inf->pid));
 
       switch_to_thread (thread);
     }

base-commit: f1a4759630b4e8b6416381e18c73c3ed6d96e374
-- 
2.51.0

Re: [PATCH] [gdb/corefiles] Fix segfault in add_thread_silent

[Guinevere Larsen]

Hi Tom,

Thanks for the thorough explanation, it makes complete sense and matches 
what you're doing in the commit.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

-- 
Cheers,
Guinevere Larsen
It/she


On 10/24/25 9:42 AM, Tom de Vries wrote:
> A user reported a segfault when loading a core file [1].
>
> The core file is from arm-linux, but I reproduced the segfault on
> x86_64-linux:
> ...
> $ gdb -q --core core
>
> warning: Can't open file /usr/bin/rs_scope during file-backed mapping note processing
>
> warning: Can't open file /lib/libc-2.26.so during file-backed mapping note processing
>
> warning: File /lib/libgcc_s.so.1 doesn't match build-id from core-file during file-backed mapping processing
>
> warning: Can't open file /lib/libm-2.26.so during file-backed mapping note processing
>
> warning: Can't open file /usr/lib/libstdc++.so.6.0.28 during file-backed mapping note processing
>
> warning: Can't open file /lib/libpthread-2.26.so during file-backed mapping note processing
>
> warning: Can't open file /lib/ld-2.26.so during file-backed mapping note processing
>
> Fatal signal: Segmentation fault
> ----- Backtrace -----
> 0x64a4ff gdb_internal_backtrace_1
> 	gdb/bt-utils.c:122
> 0x64a59d _Z22gdb_internal_backtracev
> 	gdb/bt-utils.c:175
> 0x9429e7 handle_fatal_signal
> 	gdb/event-top.c:1013
> 0x942b96 handle_sigsegv
> 	gdb/event-top.c:1090
> 0x7fbf6a64708f ???
> 	/usr/src/debug/glibc-2.40/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
> 0x5eb453 _ZN9__gnu_cxx17__normal_iteratorIPKSt4pairI6ptid_tP11thread_infoESt6vectorIS5_SaIS5_EEEC4ERKS7_
> 	/usr/include/c++/15/bits/stl_iterator.h:1059
> 0x5eb453 _ZNKSt6vectorISt4pairI6ptid_tP11thread_infoESaIS4_EE3endEv
> 	/usr/include/c++/15/bits/stl_vector.h:1029
> 0x5eae9e _ZNKSt6vectorISt4pairI6ptid_tP11thread_infoESaIS4_EE5emptyEv
> 	/usr/include/c++/15/bits/stl_vector.h:1224
> 0xa77588 _ZNK6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE5emptyEv
> 	gdb/../gdbsupport/unordered_dense.h:1351
> 0xa76533 _ZN6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE7do_findIS4_EEN9__gnu_cxx17__normal_iteratorIPSC_St6vectorISC_SD_EEERKT_
> 	gdb/../gdbsupport/unordered_dense.h:1119
> 0xa74fef _ZN6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE4findERKS4_
> 	gdb/../gdbsupport/unordered_dense.h:1773
> 0xa6f787 _ZN8inferior11find_threadE6ptid_t
> 	gdb/inferior.c:253
> 0xfc852a _Z17add_thread_silentP22process_stratum_target6ptid_t
> 	gdb/thread.c:310
> 0x73b995 core_target_open
> 	gdb/corelow.c:1111
> 0x73a095 _Z17core_file_commandPKci
> 	gdb/corelow.c:708
> 0xb6cb38 catch_command_errors
> 	gdb/main.c:510
> 0xb6e354 captured_main_1
> 	gdb/main.c:1279
> 0xb6e9a2 captured_main
> 	gdb/main.c:1372
> 0xb6eaa3 _Z8gdb_mainP18captured_main_args
> 	gdb/main.c:1401
> 0x419704 main
> 	gdb/gdb.c:38
> ...
>
> The problem happens as follows.  In core_target_open, we do:
> ...
>        if (thread == NULL)
>          thread = add_thread_silent (target, ptid_t (CORELOW_PID));
> ...
> and then in add_thread_silent:
> ...
> struct thread_info *
> add_thread_silent (process_stratum_target *targ, ptid_t ptid)
> {
>    gdb_assert (targ != nullptr);
>
>    inferior *inf = find_inferior_ptid (targ, ptid);
> ...
> find_inferior_ptid returns nullptr, which eventually causes the segfault.
>
> So, why can't we find an inferior with CORELOW_PID?
>
> A bit earlier in core_target_open, we do:
> ...
>    /* Find (or fake) the pid for the process in this core file, and
>       initialise the current inferior with that pid.  */
>    bool fake_pid_p = false;
>    int pid = bfd_core_file_pid (target->core_bfd ());
>    if (pid == 0)
>      {
>        fake_pid_p = true;
>        pid = CORELOW_PID;
>      }
>
>    inferior *inf = current_inferior ();
>    gdb_assert (inf->pid == 0);
>    inferior_appeared (inf, pid);
>    inf->fake_pid_p = fake_pid_p;
> ...
>
> The problem is that looking for an inferior using CORELOW_PID is correct in
> case fake_pid_p == true, but otherwise not.
>
> Fix this by using inf->pid instead:
> ...
> -	thread = add_thread_silent (target, ptid_t (CORELOW_PID));
> +	thread = add_thread_silent (target, ptid_t (inf->pid));
> ...
>
> Doing so enables us to continue to a gdb prompt:
> ...
> Core was generated by `/usr/bin/rs_scope -d'.
>
> ⚠️ warning: Couldn't find general-purpose registers in core file.
> (gdb)
> ...
>
> The warning seem correct.  Looking at the core file:
> ...
> $ objdump -h core
>
> core:     file format elf32-littlearm
>
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>    0 note0         00000efc  00000000  00000000  000006f4  2**0
>                    CONTENTS, READONLY
>    1 .note.linuxcore.siginfo/1037 00000080  00000000  00000000  00000848  2**2
>                    CONTENTS
>    2 .note.linuxcore.siginfo 00000080  00000000  00000000  00000848  2**2
>                    CONTENTS
>    3 .auxv         000000a0  00000000  00000000  000008dc  2**2
>                    CONTENTS
>    4 .note.linuxcore.file/1037 000003ce  00000000  00000000  00000990  2**2
>                    CONTENTS
>    5 .note.linuxcore.file 000003ce  00000000  00000000  00000990  2**2
>                    CONTENTS
>    6 .reg2/1037    00000074  00000000  00000000  00000d74  2**2
>                    CONTENTS
>    7 .reg2         00000074  00000000  00000000  00000d74  2**2
>                    CONTENTS
>    8 .reg-arm-vfp/1037 00000104  00000000  00000000  00000dfc  2**2
>                    CONTENTS
>    9 .reg-arm-vfp  00000104  00000000  00000000  00000dfc  2**2
>                    CONTENTS
>   10 .reg2/1037    00000074  00000000  00000000  00000fc4  2**2
>                    CONTENTS
>   11 .reg-arm-vfp/1037 00000104  00000000  00000000  0000104c  2**2
>                    CONTENTS
>   12 .reg2/1037    00000074  00000000  00000000  00001214  2**2
>                    CONTENTS
>   13 .reg-arm-vfp/1037 00000104  00000000  00000000  0000129c  2**2
>                    CONTENTS
>   14 .reg2/1037    00000074  00000000  00000000  00001464  2**2
>                    CONTENTS
>   15 .reg-arm-vfp/1037 00000104  00000000  00000000  000014ec  2**2
>                    CONTENTS
> ...
> indeed there's no .reg section containing the general-purpose registers.
>
> Also, the presence of both .reg2 and .reg-arm-vfp seems odd.  At least
> arm_linux_iterate_over_regset_sections thinks that a core file should have one
> or the other but not both.
>
> So, my guess would be that there's some kernel bug that writes .reg2 instead
> of .reg in the core file.
>
> I also wondered if it could be a naming problem, but the size of .reg2 is
> appropriate for .reg2 (0x74), not for .reg (0x48).
>
> Having no general-purpose registers, there's not much we can do with the core
> file, for instance we can't get a backtrace:
> ...
> (gdb) bt
> Python Exception <class 'gdb.error'>: Register 13 is not available
> (gdb)
> ...
>
> We can print a .reg-arm-vfp register:
> ...
> (gdb) p /x $d0
> $1 = 0x43444949202d2074
> ...
> but that highlights the next problem.
>
> There's only one thread:
> ...
> (gdb) info threads
>    Id   Target Id         Frame
> * 1    process 1037      <unavailable> in ?? ()
> (gdb)
> ...
> while the core file seems to contain 4 of them:
> ...
> $ objdump -h core | grep .reg-arm-vfp
>    8 .reg-arm-vfp/1037 00000104  00000000  00000000  00000dfc  2**2
>    9 .reg-arm-vfp  00000104  00000000  00000000  00000dfc  2**2
>   11 .reg-arm-vfp/1037 00000104  00000000  00000000  0000104c  2**2
>   13 .reg-arm-vfp/1037 00000104  00000000  00000000  0000129c  2**2
>   15 .reg-arm-vfp/1037 00000104  00000000  00000000  000014ec  2**2
> ...
>
> I suppose this is fixable, but I'm not sure it's worth the effort for a core
> file that has such limited usability.
>
> Tested on x86_64-linux.
>
> PR corefiles/33560
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33560
>
> [1] https://bugzilla.suse.com/show_bug.cgi?id=1251213
> ---
>   gdb/corelow.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gdb/corelow.c b/gdb/corelow.c
> index 218504bcdc8..37f38d99815 100644
> --- a/gdb/corelow.c
> +++ b/gdb/corelow.c
> @@ -1108,7 +1108,7 @@ core_target_open (const char *arg, int from_tty)
>         thread_info *thread = first_thread_of_inferior (inf);
>   
>         if (thread == NULL)
> -	thread = add_thread_silent (target, ptid_t (CORELOW_PID));
> +	thread = add_thread_silent (target, ptid_t (inf->pid));
>   
>         switch_to_thread (thread);
>       }
>
> base-commit: f1a4759630b4e8b6416381e18c73c3ed6d96e374

Re: [PATCH] [gdb/corefiles] Fix segfault in add_thread_silent

[Andrew Burgess]

Tom de Vries <tdevries@suse.de> writes:

> A user reported a segfault when loading a core file [1].

Hi Tom,

Thanks for taking a look at this.

>
> The core file is from arm-linux, but I reproduced the segfault on
> x86_64-linux:
> ...
> $ gdb -q --core core
>
> warning: Can't open file /usr/bin/rs_scope during file-backed mapping note processing
>
> warning: Can't open file /lib/libc-2.26.so during file-backed mapping note processing
>
> warning: File /lib/libgcc_s.so.1 doesn't match build-id from core-file during file-backed mapping processing
>
> warning: Can't open file /lib/libm-2.26.so during file-backed mapping note processing
>
> warning: Can't open file /usr/lib/libstdc++.so.6.0.28 during file-backed mapping note processing
>
> warning: Can't open file /lib/libpthread-2.26.so during file-backed mapping note processing
>
> warning: Can't open file /lib/ld-2.26.so during file-backed mapping note processing
>
> Fatal signal: Segmentation fault
> ----- Backtrace -----
> 0x64a4ff gdb_internal_backtrace_1
> 	gdb/bt-utils.c:122
> 0x64a59d _Z22gdb_internal_backtracev
> 	gdb/bt-utils.c:175
> 0x9429e7 handle_fatal_signal
> 	gdb/event-top.c:1013
> 0x942b96 handle_sigsegv
> 	gdb/event-top.c:1090
> 0x7fbf6a64708f ???
> 	/usr/src/debug/glibc-2.40/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
> 0x5eb453 _ZN9__gnu_cxx17__normal_iteratorIPKSt4pairI6ptid_tP11thread_infoESt6vectorIS5_SaIS5_EEEC4ERKS7_
> 	/usr/include/c++/15/bits/stl_iterator.h:1059
> 0x5eb453 _ZNKSt6vectorISt4pairI6ptid_tP11thread_infoESaIS4_EE3endEv
> 	/usr/include/c++/15/bits/stl_vector.h:1029
> 0x5eae9e _ZNKSt6vectorISt4pairI6ptid_tP11thread_infoESaIS4_EE5emptyEv
> 	/usr/include/c++/15/bits/stl_vector.h:1224
> 0xa77588 _ZNK6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE5emptyEv
> 	gdb/../gdbsupport/unordered_dense.h:1351
> 0xa76533 _ZN6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE7do_findIS4_EEN9__gnu_cxx17__normal_iteratorIPSC_St6vectorISC_SD_EEERKT_
> 	gdb/../gdbsupport/unordered_dense.h:1119
> 0xa74fef _ZN6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE4findERKS4_
> 	gdb/../gdbsupport/unordered_dense.h:1773
> 0xa6f787 _ZN8inferior11find_threadE6ptid_t
> 	gdb/inferior.c:253
> 0xfc852a _Z17add_thread_silentP22process_stratum_target6ptid_t
> 	gdb/thread.c:310
> 0x73b995 core_target_open
> 	gdb/corelow.c:1111
> 0x73a095 _Z17core_file_commandPKci
> 	gdb/corelow.c:708
> 0xb6cb38 catch_command_errors
> 	gdb/main.c:510
> 0xb6e354 captured_main_1
> 	gdb/main.c:1279
> 0xb6e9a2 captured_main
> 	gdb/main.c:1372
> 0xb6eaa3 _Z8gdb_mainP18captured_main_args
> 	gdb/main.c:1401
> 0x419704 main
> 	gdb/gdb.c:38
> ...
>
> The problem happens as follows.  In core_target_open, we do:
> ...
>       if (thread == NULL)
>         thread = add_thread_silent (target, ptid_t (CORELOW_PID));
> ...
> and then in add_thread_silent:
> ...
> struct thread_info *
> add_thread_silent (process_stratum_target *targ, ptid_t ptid)
> {
>   gdb_assert (targ != nullptr);
>
>   inferior *inf = find_inferior_ptid (targ, ptid);
> ...
> find_inferior_ptid returns nullptr, which eventually causes the segfault.
>
> So, why can't we find an inferior with CORELOW_PID?
>
> A bit earlier in core_target_open, we do:
> ...
>   /* Find (or fake) the pid for the process in this core file, and
>      initialise the current inferior with that pid.  */
>   bool fake_pid_p = false;
>   int pid = bfd_core_file_pid (target->core_bfd ());
>   if (pid == 0)
>     {
>       fake_pid_p = true;
>       pid = CORELOW_PID;
>     }
>
>   inferior *inf = current_inferior ();
>   gdb_assert (inf->pid == 0);
>   inferior_appeared (inf, pid);
>   inf->fake_pid_p = fake_pid_p;
> ...
>
> The problem is that looking for an inferior using CORELOW_PID is correct in
> case fake_pid_p == true, but otherwise not.
>
> Fix this by using inf->pid instead:
> ...
> -	thread = add_thread_silent (target, ptid_t (CORELOW_PID));
> +	thread = add_thread_silent (target, ptid_t (inf->pid));
> ...

You've skipped over all the really interesting details here.

The 

  if (thread == NULL)
    thread = add_thread_silent (target, ptid_t (CORELOW_PID));

that you quoted earlier is wrapped in:

  if (inferior_ptid == null_ptid)
  {
     ...
  }

So for the case you've identified, inf->pid has some value non-zero
value, but inferior_ptid doesn't reflect this?

I guess bfd_core_file_pid returned non-zero, which we then passed to
inferior_appeared.  So in my mind, the interesting detail here is why
does inferior_ptid not get updated in this case, but it does get updated
in "normal" cases?

Obviously I could go an figure this all out... but I guess you've
already done this.

Thanks,
Andrew

Re: [PATCH] [gdb/corefiles] Fix segfault in add_thread_silent

[Tom de Vries]

On 10/25/25 2:20 PM, Andrew Burgess wrote:
> Tom de Vries <tdevries@suse.de> writes:
> 
>> A user reported a segfault when loading a core file [1].
> 
> Hi Tom,
> 
> Thanks for taking a look at this.
> 

Sure, and thanks for this review.

>>
>> The core file is from arm-linux, but I reproduced the segfault on
>> x86_64-linux:
>> ...
>> $ gdb -q --core core
>>
>> warning: Can't open file /usr/bin/rs_scope during file-backed mapping note processing
>>
>> warning: Can't open file /lib/libc-2.26.so during file-backed mapping note processing
>>
>> warning: File /lib/libgcc_s.so.1 doesn't match build-id from core-file during file-backed mapping processing
>>
>> warning: Can't open file /lib/libm-2.26.so during file-backed mapping note processing
>>
>> warning: Can't open file /usr/lib/libstdc++.so.6.0.28 during file-backed mapping note processing
>>
>> warning: Can't open file /lib/libpthread-2.26.so during file-backed mapping note processing
>>
>> warning: Can't open file /lib/ld-2.26.so during file-backed mapping note processing
>>
>> Fatal signal: Segmentation fault
>> ----- Backtrace -----
>> 0x64a4ff gdb_internal_backtrace_1
>> 	gdb/bt-utils.c:122
>> 0x64a59d _Z22gdb_internal_backtracev
>> 	gdb/bt-utils.c:175
>> 0x9429e7 handle_fatal_signal
>> 	gdb/event-top.c:1013
>> 0x942b96 handle_sigsegv
>> 	gdb/event-top.c:1090
>> 0x7fbf6a64708f ???
>> 	/usr/src/debug/glibc-2.40/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
>> 0x5eb453 _ZN9__gnu_cxx17__normal_iteratorIPKSt4pairI6ptid_tP11thread_infoESt6vectorIS5_SaIS5_EEEC4ERKS7_
>> 	/usr/include/c++/15/bits/stl_iterator.h:1059
>> 0x5eb453 _ZNKSt6vectorISt4pairI6ptid_tP11thread_infoESaIS4_EE3endEv
>> 	/usr/include/c++/15/bits/stl_vector.h:1029
>> 0x5eae9e _ZNKSt6vectorISt4pairI6ptid_tP11thread_infoESaIS4_EE5emptyEv
>> 	/usr/include/c++/15/bits/stl_vector.h:1224
>> 0xa77588 _ZNK6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE5emptyEv
>> 	gdb/../gdbsupport/unordered_dense.h:1351
>> 0xa76533 _ZN6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE7do_findIS4_EEN9__gnu_cxx17__normal_iteratorIPSC_St6vectorISC_SD_EEERKT_
>> 	gdb/../gdbsupport/unordered_dense.h:1119
>> 0xa74fef _ZN6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE4findERKS4_
>> 	gdb/../gdbsupport/unordered_dense.h:1773
>> 0xa6f787 _ZN8inferior11find_threadE6ptid_t
>> 	gdb/inferior.c:253
>> 0xfc852a _Z17add_thread_silentP22process_stratum_target6ptid_t
>> 	gdb/thread.c:310
>> 0x73b995 core_target_open
>> 	gdb/corelow.c:1111
>> 0x73a095 _Z17core_file_commandPKci
>> 	gdb/corelow.c:708
>> 0xb6cb38 catch_command_errors
>> 	gdb/main.c:510
>> 0xb6e354 captured_main_1
>> 	gdb/main.c:1279
>> 0xb6e9a2 captured_main
>> 	gdb/main.c:1372
>> 0xb6eaa3 _Z8gdb_mainP18captured_main_args
>> 	gdb/main.c:1401
>> 0x419704 main
>> 	gdb/gdb.c:38
>> ...
>>
>> The problem happens as follows.  In core_target_open, we do:
>> ...
>>        if (thread == NULL)
>>          thread = add_thread_silent (target, ptid_t (CORELOW_PID));
>> ...
>> and then in add_thread_silent:
>> ...
>> struct thread_info *
>> add_thread_silent (process_stratum_target *targ, ptid_t ptid)
>> {
>>    gdb_assert (targ != nullptr);
>>
>>    inferior *inf = find_inferior_ptid (targ, ptid);
>> ...
>> find_inferior_ptid returns nullptr, which eventually causes the segfault.
>>
>> So, why can't we find an inferior with CORELOW_PID?
>>
>> A bit earlier in core_target_open, we do:
>> ...
>>    /* Find (or fake) the pid for the process in this core file, and
>>       initialise the current inferior with that pid.  */
>>    bool fake_pid_p = false;
>>    int pid = bfd_core_file_pid (target->core_bfd ());
>>    if (pid == 0)
>>      {
>>        fake_pid_p = true;
>>        pid = CORELOW_PID;
>>      }
>>
>>    inferior *inf = current_inferior ();
>>    gdb_assert (inf->pid == 0);
>>    inferior_appeared (inf, pid);
>>    inf->fake_pid_p = fake_pid_p;
>> ...
>>
>> The problem is that looking for an inferior using CORELOW_PID is correct in
>> case fake_pid_p == true, but otherwise not.
>>
>> Fix this by using inf->pid instead:
>> ...
>> -	thread = add_thread_silent (target, ptid_t (CORELOW_PID));
>> +	thread = add_thread_silent (target, ptid_t (inf->pid));
>> ...
> 
> You've skipped over all the really interesting details here.
> 
> The
> 
>    if (thread == NULL)
>      thread = add_thread_silent (target, ptid_t (CORELOW_PID));
> 
> that you quoted earlier is wrapped in:
> 
>    if (inferior_ptid == null_ptid)
>    {
>       ...
>    }
> 
> So for the case you've identified, inf->pid has some value non-zero
> value, but inferior_ptid doesn't reflect this?
> 

Yes.

> I guess bfd_core_file_pid returned non-zero, which we then passed to
> inferior_appeared.

Yes.

> So in my mind, the interesting detail here is why
> does inferior_ptid not get updated in this case, but it does get updated
> in "normal" cases?
> 

I generated a core file using a source file containing 
__builtin_abort(), and set a watchpoint on inferior_ptid with gdb 
loading the core file.  The variable got set during a call to 
add_to_thread_list here in core_target_open:
...
   /* Build up thread list from BFD sections, and possibly set the 

      current thread to the .reg/NN section matching the .reg 

      section.  */
   asection *reg_sect
     = bfd_get_section_by_name (target->core_bfd (), ".reg");
   for (asection *sect : gdb_bfd_sections (target->core_bfd ()))
     add_to_thread_list (sect, reg_sect, inf);
...

In the case of the core file described in this patch, this doesn't 
triggers because there are no .reg sections, so reg_sect == nullptr.

Thanks,
- Tom

> Obviously I could go an figure this all out... but I guess you've
> already done this.
> 
> Thanks,
> Andrew
> 

Re: [PATCH] [gdb/corefiles] Fix segfault in add_thread_silent

[Tom de Vries]

On 11/5/25 7:54 PM, Tom de Vries wrote:
> On 10/25/25 2:20 PM, Andrew Burgess wrote:
>> Tom de Vries <tdevries@suse.de> writes:
>>
>>> A user reported a segfault when loading a core file [1].
>>
>> Hi Tom,
>>
>> Thanks for taking a look at this.
>>
> 
> Sure, and thanks for this review.
> 
>>>
>>> The core file is from arm-linux, but I reproduced the segfault on
>>> x86_64-linux:
>>> ...
>>> $ gdb -q --core core
>>>
>>> warning: Can't open file /usr/bin/rs_scope during file-backed mapping 
>>> note processing
>>>
>>> warning: Can't open file /lib/libc-2.26.so during file-backed mapping 
>>> note processing
>>>
>>> warning: File /lib/libgcc_s.so.1 doesn't match build-id from core- 
>>> file during file-backed mapping processing
>>>
>>> warning: Can't open file /lib/libm-2.26.so during file-backed mapping 
>>> note processing
>>>
>>> warning: Can't open file /usr/lib/libstdc++.so.6.0.28 during file- 
>>> backed mapping note processing
>>>
>>> warning: Can't open file /lib/libpthread-2.26.so during file-backed 
>>> mapping note processing
>>>
>>> warning: Can't open file /lib/ld-2.26.so during file-backed mapping 
>>> note processing
>>>
>>> Fatal signal: Segmentation fault
>>> ----- Backtrace -----
>>> 0x64a4ff gdb_internal_backtrace_1
>>>     gdb/bt-utils.c:122
>>> 0x64a59d _Z22gdb_internal_backtracev
>>>     gdb/bt-utils.c:175
>>> 0x9429e7 handle_fatal_signal
>>>     gdb/event-top.c:1013
>>> 0x942b96 handle_sigsegv
>>>     gdb/event-top.c:1090
>>> 0x7fbf6a64708f ???
>>>     /usr/src/debug/glibc-2.40/signal/../sysdeps/unix/sysv/linux/ 
>>> x86_64/libc_sigaction.c:0
>>> 0x5eb453 
>>> _ZN9__gnu_cxx17__normal_iteratorIPKSt4pairI6ptid_tP11thread_infoESt6vectorIS5_SaIS5_EEEC4ERKS7_
>>>     /usr/include/c++/15/bits/stl_iterator.h:1059
>>> 0x5eb453 _ZNKSt6vectorISt4pairI6ptid_tP11thread_infoESaIS4_EE3endEv
>>>     /usr/include/c++/15/bits/stl_vector.h:1029
>>> 0x5eae9e _ZNKSt6vectorISt4pairI6ptid_tP11thread_infoESaIS4_EE5emptyEv
>>>     /usr/include/c++/15/bits/stl_vector.h:1224
>>> 0xa77588 
>>> _ZNK6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE5emptyEv
>>>     gdb/../gdbsupport/unordered_dense.h:1351
>>> 0xa76533 
>>> _ZN6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE7do_findIS4_EEN9__gnu_cxx17__normal_iteratorIPSC_St6vectorISC_SD_EEERKT_
>>>     gdb/../gdbsupport/unordered_dense.h:1119
>>> 0xa74fef 
>>> _ZN6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE4findERKS4_
>>>     gdb/../gdbsupport/unordered_dense.h:1773
>>> 0xa6f787 _ZN8inferior11find_threadE6ptid_t
>>>     gdb/inferior.c:253
>>> 0xfc852a _Z17add_thread_silentP22process_stratum_target6ptid_t
>>>     gdb/thread.c:310
>>> 0x73b995 core_target_open
>>>     gdb/corelow.c:1111
>>> 0x73a095 _Z17core_file_commandPKci
>>>     gdb/corelow.c:708
>>> 0xb6cb38 catch_command_errors
>>>     gdb/main.c:510
>>> 0xb6e354 captured_main_1
>>>     gdb/main.c:1279
>>> 0xb6e9a2 captured_main
>>>     gdb/main.c:1372
>>> 0xb6eaa3 _Z8gdb_mainP18captured_main_args
>>>     gdb/main.c:1401
>>> 0x419704 main
>>>     gdb/gdb.c:38
>>> ...
>>>
>>> The problem happens as follows.  In core_target_open, we do:
>>> ...
>>>        if (thread == NULL)
>>>          thread = add_thread_silent (target, ptid_t (CORELOW_PID));
>>> ...
>>> and then in add_thread_silent:
>>> ...
>>> struct thread_info *
>>> add_thread_silent (process_stratum_target *targ, ptid_t ptid)
>>> {
>>>    gdb_assert (targ != nullptr);
>>>
>>>    inferior *inf = find_inferior_ptid (targ, ptid);
>>> ...
>>> find_inferior_ptid returns nullptr, which eventually causes the 
>>> segfault.
>>>
>>> So, why can't we find an inferior with CORELOW_PID?
>>>
>>> A bit earlier in core_target_open, we do:
>>> ...
>>>    /* Find (or fake) the pid for the process in this core file, and
>>>       initialise the current inferior with that pid.  */
>>>    bool fake_pid_p = false;
>>>    int pid = bfd_core_file_pid (target->core_bfd ());
>>>    if (pid == 0)
>>>      {
>>>        fake_pid_p = true;
>>>        pid = CORELOW_PID;
>>>      }
>>>
>>>    inferior *inf = current_inferior ();
>>>    gdb_assert (inf->pid == 0);
>>>    inferior_appeared (inf, pid);
>>>    inf->fake_pid_p = fake_pid_p;
>>> ...
>>>
>>> The problem is that looking for an inferior using CORELOW_PID is 
>>> correct in
>>> case fake_pid_p == true, but otherwise not.
>>>
>>> Fix this by using inf->pid instead:
>>> ...
>>> -    thread = add_thread_silent (target, ptid_t (CORELOW_PID));
>>> +    thread = add_thread_silent (target, ptid_t (inf->pid));
>>> ...
>>
>> You've skipped over all the really interesting details here.
>>
>> The
>>
>>    if (thread == NULL)
>>      thread = add_thread_silent (target, ptid_t (CORELOW_PID));
>>
>> that you quoted earlier is wrapped in:
>>
>>    if (inferior_ptid == null_ptid)
>>    {
>>       ...
>>    }
>>
>> So for the case you've identified, inf->pid has some value non-zero
>> value, but inferior_ptid doesn't reflect this?
>>
> 
> Yes.
> 
>> I guess bfd_core_file_pid returned non-zero, which we then passed to
>> inferior_appeared.
> 
> Yes.
> 
>> So in my mind, the interesting detail here is why
>> does inferior_ptid not get updated in this case, but it does get updated
>> in "normal" cases?
>>
> 
> I generated a core file using a source file containing 
> __builtin_abort(), and set a watchpoint on inferior_ptid with gdb 
> loading the core file.  The variable got set during a call to 
> add_to_thread_list here in core_target_open:
> ...
>    /* Build up thread list from BFD sections, and possibly set the
>       current thread to the .reg/NN section matching the .reg
>       section.  */
>    asection *reg_sect
>      = bfd_get_section_by_name (target->core_bfd (), ".reg");
>    for (asection *sect : gdb_bfd_sections (target->core_bfd ()))
>      add_to_thread_list (sect, reg_sect, inf);
> ...
> 
> In the case of the core file described in this patch, this doesn't 
> triggers because there are no .reg sections, so reg_sect == nullptr.
> 

Ping.  Any further comments?

Thanks,
- Tom

>> Obviously I could go an figure this all out... but I guess you've
>> already done this.
>>
>> Thanks,
>> Andrew
>>
> 

Re: [PATCH] [gdb/corefiles] Fix segfault in add_thread_silent

[Tom Tromey]

>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:

Tom> Ping.  Any further comments?

I was wondering if you saw the thread on the gdb@ list and if your
scenario was the same as the one reported there, or if we're seeing two
bugs with similar symptoms.

Tom

Re: [PATCH] [gdb/corefiles] Fix segfault in add_thread_silent

[Tom de Vries]

On 11/20/25 4:18 PM, Tom Tromey wrote:
>>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
> 
> Tom> Ping.  Any further comments?
> 
> I was wondering if you saw the thread on the gdb@ list and if your
> scenario was the same as the one reported there, or if we're seeing two
> bugs with similar symptoms.

Hi Tom,

thanks for the pointer.  No, I hadn't seen that thread, and reading it 
gave me a new direction to investigate.

Simon mentioned:

> If this doesn't add any threads, then you need to dig to understand why
> BFD doesn't create the .reg pseudo sections.
and the same question applies here.

The answer is that elf32_arm_nabi_grok_prstatus expects a size of 
NT_PRSTATUS of 148, and instead it's 156.

After updating that check to allow 156 as well, I get the .reg sections.

The question then becomes, why is that size different, and what has 
changed with respect to the offsets of the various parts.

I'll try to look at 2 arm-32bit setups that I have.

Thanks,
- Tom

Re: [PATCH] [gdb/corefiles] Fix segfault in add_thread_silent

[Tom de Vries]

On 11/21/25 7:09 AM, Tom de Vries wrote:
> On 11/20/25 4:18 PM, Tom Tromey wrote:
>>>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
>>
>> Tom> Ping.  Any further comments?
>>
>> I was wondering if you saw the thread on the gdb@ list and if your
>> scenario was the same as the one reported there, or if we're seeing two
>> bugs with similar symptoms.
> 
> Hi Tom,
> 
> thanks for the pointer.  No, I hadn't seen that thread, and reading it 
> gave me a new direction to investigate.
> 
> Simon mentioned:
> 
>> If this doesn't add any threads, then you need to dig to understand why
>> BFD doesn't create the .reg pseudo sections.
> and the same question applies here.
> 
> The answer is that elf32_arm_nabi_grok_prstatus expects a size of 
> NT_PRSTATUS of 148, and instead it's 156.
> 
> After updating that check to allow 156 as well, I get the .reg sections.
> 
> The question then becomes, why is that size different, and what has 
> changed with respect to the offsets of the various parts.
> 

I wonder if it's due to the pr_exec_fdpic_loadmap and 
pr_interp_fdpic_loadmap fields in:
...
struct elf_prstatus_fdpic
{
         struct elf_prstatus_common      common;
         elf_gregset_t pr_reg;   /* GP registers */
         /* When using FDPIC, the loadmap addresses need to be
            communicated
          * to GDB in order for GDB to do the necessary relocations. 
The
          * fields (below) used to communicate this information are
            placed
          * immediately after ``pr_reg'', so that the loadmap addresses
            may
          * be viewed as part of the register set if so desired. 

          */
         unsigned long pr_exec_fdpic_loadmap;
         unsigned long pr_interp_fdpic_loadmap;
	int pr_fpvalid;         /* True if math co-processor being used.  */
};
...

Thanks,
- TOm


> I'll try to look at 2 arm-32bit setups that I have.
> 
> Thanks,
> - Tom

Re: [PATCH] [gdb/corefiles] Fix segfault in add_thread_silent

[Tom de Vries]

On 11/21/25 9:32 AM, Tom de Vries wrote:
> On 11/21/25 7:09 AM, Tom de Vries wrote:
>> On 11/20/25 4:18 PM, Tom Tromey wrote:
>>>>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
>>>
>>> Tom> Ping.  Any further comments?
>>>
>>> I was wondering if you saw the thread on the gdb@ list and if your
>>> scenario was the same as the one reported there, or if we're seeing two
>>> bugs with similar symptoms.
>>
>> Hi Tom,
>>
>> thanks for the pointer.  No, I hadn't seen that thread, and reading it 
>> gave me a new direction to investigate.
>>
>> Simon mentioned:
>>
>>> If this doesn't add any threads, then you need to dig to understand why
>>> BFD doesn't create the .reg pseudo sections.
>> and the same question applies here.
>>
>> The answer is that elf32_arm_nabi_grok_prstatus expects a size of 
>> NT_PRSTATUS of 148, and instead it's 156.
>>
>> After updating that check to allow 156 as well, I get the .reg sections.
>>
>> The question then becomes, why is that size different, and what has 
>> changed with respect to the offsets of the various parts.
>>
> 
> I wonder if it's due to the pr_exec_fdpic_loadmap and 
> pr_interp_fdpic_loadmap fields in:
> ...
> struct elf_prstatus_fdpic
> {
>          struct elf_prstatus_common      common;
>          elf_gregset_t pr_reg;   /* GP registers */
>          /* When using FDPIC, the loadmap addresses need to be
>             communicated
>           * to GDB in order for GDB to do the necessary relocations. The
>           * fields (below) used to communicate this information are
>             placed
>           * immediately after ``pr_reg'', so that the loadmap addresses
>             may
>           * be viewed as part of the register set if so desired.
>           */
>          unsigned long pr_exec_fdpic_loadmap;
>          unsigned long pr_interp_fdpic_loadmap;
>      int pr_fpvalid;         /* True if math co-processor being used.  */
> };
> ...
> 

That's got to be it.

I found here ( https://github.com/mickael-guene/fdpic_manifest ):
...
static bfd_boolean
elf32_arm_nabi_grok_prstatus (bfd *abfd, Elf_Internal_Note *note)
{
   ...
   switch (note->descsz)
     {
       ...
       case 148:         /* Linux/ARM 32-bit.  */
       ...
       case 156:         /* Linux/ARM 32-bit. Fdpic abi. */
...

Thanks,
- Tom

Re: [PATCH] [gdb/corefiles] Fix segfault in add_thread_silent

[Andrew Burgess]

Tom de Vries <tdevries@suse.de> writes:

> On 11/5/25 7:54 PM, Tom de Vries wrote:
>> On 10/25/25 2:20 PM, Andrew Burgess wrote:
>>> Tom de Vries <tdevries@suse.de> writes:
>>>
>>>> A user reported a segfault when loading a core file [1].
>>>
>>> Hi Tom,
>>>
>>> Thanks for taking a look at this.
>>>
>> 
>> Sure, and thanks for this review.
>> 
>>>>
>>>> The core file is from arm-linux, but I reproduced the segfault on
>>>> x86_64-linux:
>>>> ...
>>>> $ gdb -q --core core
>>>>
>>>> warning: Can't open file /usr/bin/rs_scope during file-backed mapping 
>>>> note processing
>>>>
>>>> warning: Can't open file /lib/libc-2.26.so during file-backed mapping 
>>>> note processing
>>>>
>>>> warning: File /lib/libgcc_s.so.1 doesn't match build-id from core- 
>>>> file during file-backed mapping processing
>>>>
>>>> warning: Can't open file /lib/libm-2.26.so during file-backed mapping 
>>>> note processing
>>>>
>>>> warning: Can't open file /usr/lib/libstdc++.so.6.0.28 during file- 
>>>> backed mapping note processing
>>>>
>>>> warning: Can't open file /lib/libpthread-2.26.so during file-backed 
>>>> mapping note processing
>>>>
>>>> warning: Can't open file /lib/ld-2.26.so during file-backed mapping 
>>>> note processing
>>>>
>>>> Fatal signal: Segmentation fault
>>>> ----- Backtrace -----
>>>> 0x64a4ff gdb_internal_backtrace_1
>>>>     gdb/bt-utils.c:122
>>>> 0x64a59d _Z22gdb_internal_backtracev
>>>>     gdb/bt-utils.c:175
>>>> 0x9429e7 handle_fatal_signal
>>>>     gdb/event-top.c:1013
>>>> 0x942b96 handle_sigsegv
>>>>     gdb/event-top.c:1090
>>>> 0x7fbf6a64708f ???
>>>>     /usr/src/debug/glibc-2.40/signal/../sysdeps/unix/sysv/linux/ 
>>>> x86_64/libc_sigaction.c:0
>>>> 0x5eb453 
>>>> _ZN9__gnu_cxx17__normal_iteratorIPKSt4pairI6ptid_tP11thread_infoESt6vectorIS5_SaIS5_EEEC4ERKS7_
>>>>     /usr/include/c++/15/bits/stl_iterator.h:1059
>>>> 0x5eb453 _ZNKSt6vectorISt4pairI6ptid_tP11thread_infoESaIS4_EE3endEv
>>>>     /usr/include/c++/15/bits/stl_vector.h:1029
>>>> 0x5eae9e _ZNKSt6vectorISt4pairI6ptid_tP11thread_infoESaIS4_EE5emptyEv
>>>>     /usr/include/c++/15/bits/stl_vector.h:1224
>>>> 0xa77588 
>>>> _ZNK6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE5emptyEv
>>>>     gdb/../gdbsupport/unordered_dense.h:1351
>>>> 0xa76533 
>>>> _ZN6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE7do_findIS4_EEN9__gnu_cxx17__normal_iteratorIPSC_St6vectorISC_SD_EEERKT_
>>>>     gdb/../gdbsupport/unordered_dense.h:1119
>>>> 0xa74fef 
>>>> _ZN6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE4findERKS4_
>>>>     gdb/../gdbsupport/unordered_dense.h:1773
>>>> 0xa6f787 _ZN8inferior11find_threadE6ptid_t
>>>>     gdb/inferior.c:253
>>>> 0xfc852a _Z17add_thread_silentP22process_stratum_target6ptid_t
>>>>     gdb/thread.c:310
>>>> 0x73b995 core_target_open
>>>>     gdb/corelow.c:1111
>>>> 0x73a095 _Z17core_file_commandPKci
>>>>     gdb/corelow.c:708
>>>> 0xb6cb38 catch_command_errors
>>>>     gdb/main.c:510
>>>> 0xb6e354 captured_main_1
>>>>     gdb/main.c:1279
>>>> 0xb6e9a2 captured_main
>>>>     gdb/main.c:1372
>>>> 0xb6eaa3 _Z8gdb_mainP18captured_main_args
>>>>     gdb/main.c:1401
>>>> 0x419704 main
>>>>     gdb/gdb.c:38
>>>> ...
>>>>
>>>> The problem happens as follows.  In core_target_open, we do:
>>>> ...
>>>>        if (thread == NULL)
>>>>          thread = add_thread_silent (target, ptid_t (CORELOW_PID));
>>>> ...
>>>> and then in add_thread_silent:
>>>> ...
>>>> struct thread_info *
>>>> add_thread_silent (process_stratum_target *targ, ptid_t ptid)
>>>> {
>>>>    gdb_assert (targ != nullptr);
>>>>
>>>>    inferior *inf = find_inferior_ptid (targ, ptid);
>>>> ...
>>>> find_inferior_ptid returns nullptr, which eventually causes the 
>>>> segfault.
>>>>
>>>> So, why can't we find an inferior with CORELOW_PID?
>>>>
>>>> A bit earlier in core_target_open, we do:
>>>> ...
>>>>    /* Find (or fake) the pid for the process in this core file, and
>>>>       initialise the current inferior with that pid.  */
>>>>    bool fake_pid_p = false;
>>>>    int pid = bfd_core_file_pid (target->core_bfd ());
>>>>    if (pid == 0)
>>>>      {
>>>>        fake_pid_p = true;
>>>>        pid = CORELOW_PID;
>>>>      }
>>>>
>>>>    inferior *inf = current_inferior ();
>>>>    gdb_assert (inf->pid == 0);
>>>>    inferior_appeared (inf, pid);
>>>>    inf->fake_pid_p = fake_pid_p;
>>>> ...
>>>>
>>>> The problem is that looking for an inferior using CORELOW_PID is 
>>>> correct in
>>>> case fake_pid_p == true, but otherwise not.
>>>>
>>>> Fix this by using inf->pid instead:
>>>> ...
>>>> -    thread = add_thread_silent (target, ptid_t (CORELOW_PID));
>>>> +    thread = add_thread_silent (target, ptid_t (inf->pid));
>>>> ...
>>>
>>> You've skipped over all the really interesting details here.
>>>
>>> The
>>>
>>>    if (thread == NULL)
>>>      thread = add_thread_silent (target, ptid_t (CORELOW_PID));
>>>
>>> that you quoted earlier is wrapped in:
>>>
>>>    if (inferior_ptid == null_ptid)
>>>    {
>>>       ...
>>>    }
>>>
>>> So for the case you've identified, inf->pid has some value non-zero
>>> value, but inferior_ptid doesn't reflect this?
>>>
>> 
>> Yes.
>> 
>>> I guess bfd_core_file_pid returned non-zero, which we then passed to
>>> inferior_appeared.
>> 
>> Yes.
>> 
>>> So in my mind, the interesting detail here is why
>>> does inferior_ptid not get updated in this case, but it does get updated
>>> in "normal" cases?
>>>
>> 
>> I generated a core file using a source file containing 
>> __builtin_abort(), and set a watchpoint on inferior_ptid with gdb 
>> loading the core file.  The variable got set during a call to 
>> add_to_thread_list here in core_target_open:
>> ...
>>    /* Build up thread list from BFD sections, and possibly set the
>>       current thread to the .reg/NN section matching the .reg
>>       section.  */
>>    asection *reg_sect
>>      = bfd_get_section_by_name (target->core_bfd (), ".reg");
>>    for (asection *sect : gdb_bfd_sections (target->core_bfd ()))
>>      add_to_thread_list (sect, reg_sect, inf);
>> ...
>> 
>> In the case of the core file described in this patch, this doesn't 
>> triggers because there are no .reg sections, so reg_sect == nullptr.
>> 
>
> Ping.  Any further comments?
>

Tom,

Sorry for loosing track of this thread, and thanks for the explanation,
that makes sense.

I do think it is worth chasing what's going wrong in BFD to find out why
we cannot find the .reg sections.  But that said, the core file is an
external input, so we cannot rely on it actually _having_ the required
.reg notes/sections, so GDB should be able to handle this case.

So, with that in mind, I agree that your patch should go in:

Approved-By: Andrew Burgess <aburgess@redhat.com>

But I think we (you?) should continue to investigate BFD to see what's
going wrong there (though it looks like you already have it mostly
figured out).

Thanks,
Andrew

Re: [PATCH] [gdb/corefiles] Fix segfault in add_thread_silent

[Tom de Vries]

On 11/21/25 12:10 PM, Andrew Burgess wrote:
> Tom de Vries <tdevries@suse.de> writes:
> 
>> On 11/5/25 7:54 PM, Tom de Vries wrote:
>>> On 10/25/25 2:20 PM, Andrew Burgess wrote:
>>>> Tom de Vries <tdevries@suse.de> writes:
>>>>
>>>>> A user reported a segfault when loading a core file [1].
>>>>
>>>> Hi Tom,
>>>>
>>>> Thanks for taking a look at this.
>>>>
>>>
>>> Sure, and thanks for this review.
>>>
>>>>>
>>>>> The core file is from arm-linux, but I reproduced the segfault on
>>>>> x86_64-linux:
>>>>> ...
>>>>> $ gdb -q --core core
>>>>>
>>>>> warning: Can't open file /usr/bin/rs_scope during file-backed mapping
>>>>> note processing
>>>>>
>>>>> warning: Can't open file /lib/libc-2.26.so during file-backed mapping
>>>>> note processing
>>>>>
>>>>> warning: File /lib/libgcc_s.so.1 doesn't match build-id from core-
>>>>> file during file-backed mapping processing
>>>>>
>>>>> warning: Can't open file /lib/libm-2.26.so during file-backed mapping
>>>>> note processing
>>>>>
>>>>> warning: Can't open file /usr/lib/libstdc++.so.6.0.28 during file-
>>>>> backed mapping note processing
>>>>>
>>>>> warning: Can't open file /lib/libpthread-2.26.so during file-backed
>>>>> mapping note processing
>>>>>
>>>>> warning: Can't open file /lib/ld-2.26.so during file-backed mapping
>>>>> note processing
>>>>>
>>>>> Fatal signal: Segmentation fault
>>>>> ----- Backtrace -----
>>>>> 0x64a4ff gdb_internal_backtrace_1
>>>>>      gdb/bt-utils.c:122
>>>>> 0x64a59d _Z22gdb_internal_backtracev
>>>>>      gdb/bt-utils.c:175
>>>>> 0x9429e7 handle_fatal_signal
>>>>>      gdb/event-top.c:1013
>>>>> 0x942b96 handle_sigsegv
>>>>>      gdb/event-top.c:1090
>>>>> 0x7fbf6a64708f ???
>>>>>      /usr/src/debug/glibc-2.40/signal/../sysdeps/unix/sysv/linux/
>>>>> x86_64/libc_sigaction.c:0
>>>>> 0x5eb453
>>>>> _ZN9__gnu_cxx17__normal_iteratorIPKSt4pairI6ptid_tP11thread_infoESt6vectorIS5_SaIS5_EEEC4ERKS7_
>>>>>      /usr/include/c++/15/bits/stl_iterator.h:1059
>>>>> 0x5eb453 _ZNKSt6vectorISt4pairI6ptid_tP11thread_infoESaIS4_EE3endEv
>>>>>      /usr/include/c++/15/bits/stl_vector.h:1029
>>>>> 0x5eae9e _ZNKSt6vectorISt4pairI6ptid_tP11thread_infoESaIS4_EE5emptyEv
>>>>>      /usr/include/c++/15/bits/stl_vector.h:1224
>>>>> 0xa77588
>>>>> _ZNK6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE5emptyEv
>>>>>      gdb/../gdbsupport/unordered_dense.h:1351
>>>>> 0xa76533
>>>>> _ZN6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE7do_findIS4_EEN9__gnu_cxx17__normal_iteratorIPSC_St6vectorISC_SD_EEERKT_
>>>>>      gdb/../gdbsupport/unordered_dense.h:1119
>>>>> 0xa74fef
>>>>> _ZN6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE4findERKS4_
>>>>>      gdb/../gdbsupport/unordered_dense.h:1773
>>>>> 0xa6f787 _ZN8inferior11find_threadE6ptid_t
>>>>>      gdb/inferior.c:253
>>>>> 0xfc852a _Z17add_thread_silentP22process_stratum_target6ptid_t
>>>>>      gdb/thread.c:310
>>>>> 0x73b995 core_target_open
>>>>>      gdb/corelow.c:1111
>>>>> 0x73a095 _Z17core_file_commandPKci
>>>>>      gdb/corelow.c:708
>>>>> 0xb6cb38 catch_command_errors
>>>>>      gdb/main.c:510
>>>>> 0xb6e354 captured_main_1
>>>>>      gdb/main.c:1279
>>>>> 0xb6e9a2 captured_main
>>>>>      gdb/main.c:1372
>>>>> 0xb6eaa3 _Z8gdb_mainP18captured_main_args
>>>>>      gdb/main.c:1401
>>>>> 0x419704 main
>>>>>      gdb/gdb.c:38
>>>>> ...
>>>>>
>>>>> The problem happens as follows.  In core_target_open, we do:
>>>>> ...
>>>>>         if (thread == NULL)
>>>>>           thread = add_thread_silent (target, ptid_t (CORELOW_PID));
>>>>> ...
>>>>> and then in add_thread_silent:
>>>>> ...
>>>>> struct thread_info *
>>>>> add_thread_silent (process_stratum_target *targ, ptid_t ptid)
>>>>> {
>>>>>     gdb_assert (targ != nullptr);
>>>>>
>>>>>     inferior *inf = find_inferior_ptid (targ, ptid);
>>>>> ...
>>>>> find_inferior_ptid returns nullptr, which eventually causes the
>>>>> segfault.
>>>>>
>>>>> So, why can't we find an inferior with CORELOW_PID?
>>>>>
>>>>> A bit earlier in core_target_open, we do:
>>>>> ...
>>>>>     /* Find (or fake) the pid for the process in this core file, and
>>>>>        initialise the current inferior with that pid.  */
>>>>>     bool fake_pid_p = false;
>>>>>     int pid = bfd_core_file_pid (target->core_bfd ());
>>>>>     if (pid == 0)
>>>>>       {
>>>>>         fake_pid_p = true;
>>>>>         pid = CORELOW_PID;
>>>>>       }
>>>>>
>>>>>     inferior *inf = current_inferior ();
>>>>>     gdb_assert (inf->pid == 0);
>>>>>     inferior_appeared (inf, pid);
>>>>>     inf->fake_pid_p = fake_pid_p;
>>>>> ...
>>>>>
>>>>> The problem is that looking for an inferior using CORELOW_PID is
>>>>> correct in
>>>>> case fake_pid_p == true, but otherwise not.
>>>>>
>>>>> Fix this by using inf->pid instead:
>>>>> ...
>>>>> -    thread = add_thread_silent (target, ptid_t (CORELOW_PID));
>>>>> +    thread = add_thread_silent (target, ptid_t (inf->pid));
>>>>> ...
>>>>
>>>> You've skipped over all the really interesting details here.
>>>>
>>>> The
>>>>
>>>>     if (thread == NULL)
>>>>       thread = add_thread_silent (target, ptid_t (CORELOW_PID));
>>>>
>>>> that you quoted earlier is wrapped in:
>>>>
>>>>     if (inferior_ptid == null_ptid)
>>>>     {
>>>>        ...
>>>>     }
>>>>
>>>> So for the case you've identified, inf->pid has some value non-zero
>>>> value, but inferior_ptid doesn't reflect this?
>>>>
>>>
>>> Yes.
>>>
>>>> I guess bfd_core_file_pid returned non-zero, which we then passed to
>>>> inferior_appeared.
>>>
>>> Yes.
>>>
>>>> So in my mind, the interesting detail here is why
>>>> does inferior_ptid not get updated in this case, but it does get updated
>>>> in "normal" cases?
>>>>
>>>
>>> I generated a core file using a source file containing
>>> __builtin_abort(), and set a watchpoint on inferior_ptid with gdb
>>> loading the core file.  The variable got set during a call to
>>> add_to_thread_list here in core_target_open:
>>> ...
>>>     /* Build up thread list from BFD sections, and possibly set the
>>>        current thread to the .reg/NN section matching the .reg
>>>        section.  */
>>>     asection *reg_sect
>>>       = bfd_get_section_by_name (target->core_bfd (), ".reg");
>>>     for (asection *sect : gdb_bfd_sections (target->core_bfd ()))
>>>       add_to_thread_list (sect, reg_sect, inf);
>>> ...
>>>
>>> In the case of the core file described in this patch, this doesn't
>>> triggers because there are no .reg sections, so reg_sect == nullptr.
>>>
>>
>> Ping.  Any further comments?
>>
> 
> Tom,
> 
> Sorry for loosing track of this thread, and thanks for the explanation,
> that makes sense.
> 
> I do think it is worth chasing what's going wrong in BFD to find out why
> we cannot find the .reg sections.  But that said, the core file is an
> external input, so we cannot rely on it actually _having_ the required
> .reg notes/sections, so GDB should be able to handle this case.
> 
> So, with that in mind, I agree that your patch should go in:
> 
> Approved-By: Andrew Burgess <aburgess@redhat.com>
> 

Thanks, I've pushed this.  Before pushing I've updated the commit 
message to include my theory about why the .reg pseudo-section is missing.

> But I think we (you?) should continue to investigate BFD to see what's
> going wrong there (though it looks like you already have it mostly
> figured out).
> 

I think so, yes.  I'll submit a patch for elf32_arm_nabi_grok_prstatus 
to the @binutils.

Thanks,
- Tom

> Thanks,
> Andrew
> 

Re: [PATCH] [gdb/corefiles] Fix segfault in add_thread_silent

[Simon Marchi]

On 2025-11-21 06:10, Andrew Burgess wrote:
> Tom,
> 
> Sorry for loosing track of this thread, and thanks for the explanation,
> that makes sense.
> 
> I do think it is worth chasing what's going wrong in BFD to find out why
> we cannot find the .reg sections.  But that said, the core file is an
> external input, so we cannot rely on it actually _having_ the required
> .reg notes/sections, so GDB should be able to handle this case.
> 
> So, with that in mind, I agree that your patch should go in:
> 
> Approved-By: Andrew Burgess <aburgess@redhat.com>
> 
> But I think we (you?) should continue to investigate BFD to see what's
> going wrong there (though it looks like you already have it mostly
> figured out).

Also, better warning or error messages would really help.  Like "PRSTATUS
note with unexpected size detected".

Simon