Re: Does gdb debuginfod download libc etc.?

[Andrew Burgess via Gdb <gdb@sourceware.org>]

Paul Smith <psmith@gnu.org> writes:

> On Wed, 2026-03-11 at 09:28 +0000, Andrew Burgess wrote:
>> I started working on cleaning up the patch ready for submission to
>> master, but I'm pretty busy for the next few days, so it'll probably
>> be next week now before I post anything.
>
> Hi Andrew; working more with this patch I think there might be an issue
> with it: when I use it with my cores that don't have NT_FILE it works
> well.  But, when I use it with a core file that DOES have NT_FILE, it
> has some odd behavior: basically some of the filenames found during the
> map have invalid names (names with control characters etc.)
>
> Note, this is from GDB 17.1 with your patch applied, working with a
> normal core file generated by the Linux kernel (via kill -6); I can see
> from readelf -n that the NT_FILE section looks normal with no funky
> characters in the filenames.
>
> GDB shows:
>
> [core-load] build_file_mappings: enter
>   [core-load] operator(): start = 0x0, end = 0x67dc, filename = NONE, build-id = NONE
>   [core-load] operator(): start = 0x200000, end = 0x521000, filename = , build-id = 38abc1e51499f5610bdd123e6336f7cb0f4146c2
>   [core-load] operator(): start = 0x521000, end = 0x728000, filename = , build-id = NONE
>   [core-load] operator(): start = 0x728000, end = 0x735000, filename = ^F, build-id = NONE
>
> (here the ^F in the filename is the actual ASCII char 15).  Then some
> OK stuff then more problematic filenames:
>
>   [core-load] operator(): start = 0x737000, end = 0x947000, filename = NONE, build-id = NONE
>   [core-load] operator(): start = 0x7fa8d9a00000, end = 0x7fa8e0400000, filename = NONE, build-id = NONE
>   [core-load] operator(): start = 0x7fa8e1600000, end = 0x7fa8e8c00000, filename = NONE, build-id = NONE
> ...
>   [core-load] operator(): start = 0x7fa93a398000, end = 0x7fa93a3c0000, filename = <D6>^A, build-id = 095c7ba148aeca81668091f718047078d57efddb
>   [core-load] operator(): start = 0x7fa93a3c0000, end = 0x7fa93a555000, filename = , build-id = NONE
>   [core-load] operator(): start = 0x7fa93a555000, end = 0x7fa93a5ad000, filename = , build-id = NONE
>   [core-load] operator(): start = 0x7fa93a5ad000, end = 0x7fa93a5ae000, filename = e, build-id = NONE
>   [core-load] operator(): start = 0x7fa93a5ae000, end = 0x7fa93a5b2000, filename = P^A, build-id = NONE
>   [core-load] operator(): start = 0x7fa93a5b2000, end = 0x7fa93a5b4000, filename = , build-id = NONE
>   [core-load] operator(): start = 0x7fa93a5b4000, end = 0x7fa93a5c3000, filename = NONE, build-id = NONE
>   [core-load] operator(): start = 0x7fa93a5c3000, end = 0x7fa93a5c4000, filename = E^A, build-id = 34f1f6beeaed8ab30ee4056ff1cc053f8d05c153
>   [core-load] operator(): start = 0x7fa93a5c4000, end = 0x7fa93a5c5000, filename = , build-id = NONE
>   [core-load] operator(): start = 0x7fa93a5c5000, end = 0x7fa93a5c6000, filename = X, build-id = NONE
> ...
>   [core-load] operator(): start = 0x7fa93a5cb000, end = 0x7fa93a5e2000, filename = , build-id = NONE
>   [core-load] operator(): start = 0x7fa93a5e2000, end = 0x7fa93a5e6000, filename = , build-id = NONE
>   [core-load] operator(): start = 0x7fa93a5e6000, end = 0x7fa93a5e7000, filename = ^?^K, build-id = NONE
>   [core-load] operator(): start = 0x7fa93a5e7000, end = 0x7fa93a5e8000, filename = <80>^K, build-id = NONE
>   [core-load] operator(): start = 0x7fa93a5e8000, end = 0x7fa93a5f6000, filename = /usr/l <A4>^?^K, build-id = 2ac471af4796e5b69e0e2dde85c3d3dacdcc0b3d
>   [core-load] operator(): start = 0x7fa93a5f6000, end = 0x7fa93a672000, filename = , build-id = NONE
>   [core-load] operator(): start = 0x7fa93a672000, end = 0x7fa93a6cd000, filename = /usr/l<E0><A3>^?^K, build-id = NONE
>   [core-load] operator(): start = 0x7fa93a6cd000, end = 0x7fa93a6ce000, filename = , build-id = NONE
>   [core-load] operator(): start = 0x7fa93a6ce000, end = 0x7fa93a6cf000, filename = /usr/l@<A4>^?^K, build-id = NONE
>
> I think something here might have messed up the parsing of the filename
> section of the NT_FILE section?  I'll try to look into this and see if
> I can find it.

I suspect this is a use-after-free bug.  Try the patch below and let me
know if this fixes things.

Thanks,
Andrew

---

diff --git i/gdb/linux-tdep.c w/gdb/linux-tdep.c
index 27443f7fb4b..148430d6d0a 100644
--- i/gdb/linux-tdep.c
+++ w/gdb/linux-tdep.c
@@ -1169,6 +1169,9 @@ linux_read_core_file_mappings
   /* The start address of each mapping.  */
   gdb::unordered_set<ULONGEST> mapping_start_addr_set;
 
+  /* ... */
+  gdb::byte_vector contents;
+
   /* It's not required that the NT_FILE note exists, so return silently
      if it's not found.  Beyond this point though, we'll complain
      if problems are found.  */
@@ -1185,7 +1188,7 @@ linux_read_core_file_mappings
 	  return;
 	}
 
-      gdb::byte_vector contents (note_size);
+      contents.resize (note_size);
       if (!bfd_get_section_contents (cbfd, section, contents.data (), 0,
 				     note_size))
 	{