Glibc commit causing regression in gdb

[Emil Velikov <emil.l.velikov@gmail.com>]

Greetings everyone,

We have recently received a regression report in Arch Linux, where gdb
attach fails with some applications.
In particular, the issue originates in glibc 2.33, while gdb used is
10.1 and is 100% reproducible (here) with steam and gimp.

Note that explicitly rebuilding gdb explicitly against the glibc does not help.

After some digging I found the offending glibc commit
1daccf403b1bd86370eb94edca794dc106d02039 ("nptl: Move stack list
variables into _rtld_global"). With the said commit the
td_ta_map_lwp2thr() call in GDB fails, resulting in the infamous

Error while reading shared library symbols for /usr/lib/libpthread.so.0:
Cannot find user-level thread for LWP 2999060: generic error


Can anyone confirm if the issue is reproducible with other distros? Is
there some gdb patch to fix this, or alternatively is it safe to ship
a revert upstream and/or within the Arch Linux package?

Bear in mind that I'm happy to get this issue resolved properly, yet
this is my first time seriously looking at the glibc codebase. For my
initial investigation I force-enabled LOG() and added a few extra
notations.

- Vanilla glibc 2.33
td_init
td_ta_new
td_init
td_ta_new
td_ta_map_lwp2thr
__td_ta_stack_user has failed // newly added LOG

- Vanilla glibc 2.33 with offending commit reverted
td_init
td_ta_new
td_init
td_ta_new
td_ta_map_lwp2thr
__td_ta_lookup_th_unique // newly added LOG entry
td_thr_get_info
... above three are repeated a lot, until the end

Thanks
Emil
[1] https://bugs.archlinux.org/task/69657