Is GDB 16 expected to work?

[gvl2023]

Not getting much luck with using GDB 16.3-2.el9 debugger, thread and variable views not updating and basically stepping through the code is unusable. GDB 12.1 however works.

[jonahgraham]

In the general sense absolutely it should work. I have used it without noticing anything wrong. Specifically I have been using gdb 16.3 as packaged by Ubuntu 25.10 to debug JVM and GTK3+GTK4 code while I have been working on GTK4 Full Support

The test machine (e.g. this run) uses GDB 15 so it could very well be that there are issues with GDB 16.

Can you share more details of your setup?

[gvl2023]

Could you please post a link to GDB ticket regarding this issue when you get to it?

Well, while it does appear the issue is real, I find it hard to believe that there weren't at least ten thousand fat-fingered evaluation commands issued during debugging since 16.3 was released at the end of April earlier this year and yet this issue doesn't seem to be widespread. Which makes me think it's a fairly isolated case specific to my environment. I just ran find . -name '*.so' in the product directory which produced 2895 hits. Granted, most are probably unused, this gives an idea what I'm dealing with here. Frankly, I don't even know where to begin with a repro case.

[jonahgraham]

I just ran find . -name '*.so' in the product directory which produced 2895 hits.

I think this is likely a contribution to the problem - since s_x isn't in scope as a local variable, then GDB is searching all globals for it, which means looking in the debug information of all the loaded .so files. It makes sense on a big project that could be very slow. It makes me wonder if info variables would be similarly slow.

Another contributing factor could be the Qt Python contributions to GDB for pretty printing (such as these ones). I found one slightly related report on bugzilla.

You can try disabling python pretty printing to see if that is part of the problem:

With that unchecked the pretty printers are not switched on by CDT, but they can still be switched on by other factors in the system, so you can check if they are on and disable them:

(gdb) info pretty-printer 
global pretty-printers:
  builtin
objfile /lib/x86_64-linux-gnu/libglib-2.0.so.0 pretty-printers:
  pretty_printer_lookup
objfile /lib/x86_64-linux-gnu/libgobject-2.0.so.0 pretty-printers:
  pretty_printer_lookup
objfile /lib/x86_64-linux-gnu/libstdc++.so.6 pretty-printers:
  libstdc++-v6
(gdb) disable pretty-printer 
3 printers disabled
0 of 3 printers enabled
(gdb) info pretty-printer 
global pretty-printers:
  builtin [disabled]
objfile /lib/x86_64-linux-gnu/libglib-2.0.so.0 pretty-printers:
  pretty_printer_lookup [disabled]
objfile /lib/x86_64-linux-gnu/libgobject-2.0.so.0 pretty-printers:
  pretty_printer_lookup [disabled]
objfile /lib/x86_64-linux-gnu/libstdc++.so.6 pretty-printers:
  libstdc++-v6 [disabled]

See full documentation on GDB pretty printers here

There may be other parts of Python involved too.

[jonahgraham]

Eclipse part may want to grow a timed check for the command to complete so users can see what's going on.

Yes - that is a good idea. A second or so limit on commands before (better) user feedback should be part of CDT.

I see from the gdb bug linked above that Qt creator has a 40 second timeout and then gives user option to abort GDB.

[gvl2023]

It makes sense on a big project that could be very slow.

Right, but gdb 12.1 manages a significantly quicker turnaround everything else being equal, that's why I think it's a regression.

[jonahgraham]

100% there is a regression - if we can make a reproducible test case then we can file it with gdb. You can try to file it without a reproducible test case or just send an email to gdb mail list to see if anyone there has more insight.

And regardless of whether it is a gdb bug or not, improving cdt so (at a minimum) a user can be advised of what is going wrong, should be done.