[CRITICAL BUG] GDB broken with last stable update

The Latest stable update Completely broke GDB, it is literally UNUSEABLE now, i don’t know how this didn’t get found in testing, but it didn’t. Every single attempt to attach to a 32bit or 64bit program fails with
LWP 50578: generic error

Example output when attaching to a 32 bit Application:

GNU gdb (GDB) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) attach 55917
Attaching to process 55917
[New LWP 55918]
[New LWP 55919]
[New LWP 55920]
[New LWP 55921]
[New LWP 55922]
[New LWP 55923]
[New LWP 55924]
[New LWP 55925]
[New LWP 55926]
[New LWP 55927]
[New LWP 55928]
[New LWP 55929]
[New LWP 55930]
[New LWP 55931]
[New LWP 55932]
[New LWP 55933]
[New LWP 55934]
[New LWP 55935]
[New LWP 55936]
[New LWP 55940]
[New LWP 55941]
[New LWP 55942]
[New LWP 56011]
[New LWP 56013]
[New LWP 56014]
warning: Could not load shared library symbols for bin/launcher.so.
Do you need "set solib-search-path" or "set sysroot"?
Error while reading shared library symbols for /usr/lib32/libpthread.so.0:
Cannot find user-level thread for LWP 56014: generic error
0xf7f08b59 in __kernel_vsyscall ()
(gdb) c
[LWP 56014 exited]
Cannot find user-level thread for LWP 56044: generic error
(gdb) q
A debugging session is active.

        Inferior 1 [process 55917] will be detached.

Quit anyway? (y or n) y

As you can see, the error pops up whenever you try to do anything, you cannot even unpause the program while gdb is attached, and any kind of actions will fail entirely.

Steps to reproduce:

  1. sudo gdb
  2. attach (any pid)
  3. It fails
1 Like

I’ve got no exact fix right now, but it should be resolved ASAP.

according to the sourceware wiki:

9. GDB reports “Cannot find user-level thread for LWP 23957: generic error”, how do I fix this?

  • There are several common causes:
    • You have a mismatch between libthread_db.so.1 and libpthread.so.0 (this most often happens when you have multiple installations of glibc, or when you debug a program on remote target, and host and target have different glibc versions).
    • You are using 64-bit debugger to debug 32-bit program, and your kernel has a 32-bit ptrace emulation bug. FIXME: add reference to specific kernel fix.This has also been known to happen when one of DOSEMU’s signal handlers is invoked from DPMI context, where the $gs register has a value different from what GDB and/or libthread_db.so.0 expect; found running the program under gdbserver to alleviate the problem, at least with version on i386.

Another note. it does not seem to be all applications, but alot of them. It’s also present on arch, so it seems to be an upstream bug.

Example applications: Telegram, Steam, Source games

Just going to elaborate on this after @BenCat07 alerted me to this, this issue also affects Archlinux and therefore should not belong on the Manjaro Forum. We’re using a workaround for now, don’t really feel like making a bug report on the Archlinux bug tracker right now tho.

I have also just encountered this bug while trying to attach to a python process with gdb.
Does anybody know a workaround how to debug programs anyway?

The error message is similar to the one from the OP:

Attaching to process 43394
[New LWP 43399]
[New LWP 43400]
[New LWP 43404]
[New LWP 43414]
[New LWP 43415]
[New LWP 43422]
[New LWP 43423]
[New LWP 43424]
[New LWP 43425]
[New LWP 43426]
Error while reading shared library symbols for /usr/lib/libpthread.so.0:
Cannot find user-level thread for LWP 43426: generic error
--Type <RET> for more, q to quit, c to continue without paging--c
0x00007f0a842e339e in epoll_wait () from /usr/lib/libc.so.6

I tested it with Signal Desktop, which does also not work, but debugging Gedit seems to work.