Attempting to evaluate "mixed/uper-case" C/C++ fundamental types (such as "output LONG" or "output Int") will cause GDB to try to fully expand the whole symbol table. Depending on how large the binary we are debugging, this could cause GDB to hang for several minutes and has been observed to cause Out-of-Memory issues on some circumstances. Via a git bisect, it was observed that this regression first occurs on the commit which enables the new DWARF indexer: https://sourceware.org/pipermail/gdb-patches/2022-April/187417.html Easiest way to reproduce this issue is to attempt to run GDB on a debug build of GDB: $ gdb ./gdb/gdb (gdb) start Temporary breakpoint 1 at 0x410675: file gdb.c, line 28. Starting program: /path/to/binutils-gdb/gdb/gdb [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Temporary breakpoint 1, main (argc=1, argv=0x7fffffffd578) at gdb.c:28 28 memset (&args, 0, sizeof args); (gdb) output LONG No symbol "LONG" in current context. This will take ~20-30 seconds, though as stated above with larger binaries it has been observed to take make longer or cause Out-of-Memory. Worth noting the hang does not occur if we attempt to output other non-existent symbols such as "output NOTREAL".
cooked_index_functions::expand_symtabs_matching defers to the index, which uses case-insensitive lookup to handle things like Ada and Fortran. This probably needs some refinement. Maybe a lookup_name ought to carry a language along with it. Anyway more filtering could be done in the inner loop of that function.
Closing this as a dup, since it seems to be basically the same problem as the other bug, and that bug has a patch. Worth noting that this problem is reported as being fixed by that patch as well. *** This bug has been marked as a duplicate of bug 30520 ***