When debugging with GDB during one debug session it becomes slower and slower over time. Even simplest operations like step over and step into can take dozens of seconds and sometimes even minutes.
I was debugging a rather big project (Chromium browser). The only reason I could think of was that gdb is getting slower over time because it loads more and more symbols and it takes longer to work with them. However Chromium compiles entire code into one huge executable, which contains all symbols which should be loaded in the very beginning. Thus symbol database won’t grow during the debugging. Moreover why would one need to look up symbols just to perform step over or step into operation?
While testing I have tried using gdb with front-ends (Eclipse, QtCreator, Emacs) and from the command line to confirm that this is not an IDE problem. Both use cases demonstrate same problem, however it seems like it starts to appear sooner in IDEs (probably because IDE also loads symbols for the watch view, call stack, list of threads etc.).
Why is GDB getting slower? Is it a design flaw, a bug or some specific problem in my computer? Are there any free alternatives to GDB that work faster?
It’s a bug. Try newer version of GDB (preferably current CVS snapshot). If the problem is still there, report it to GDB bugzilla with repro instructions.
GDB loads partial symbols (
psymbols) on startup, and reads more “on-demand”, so some growth is expected.In order to step over or into, GDB would likely need line tables for the current translation unit (TU). If your “step into” operation takes you to a new TU, then new line tables would have to be loaded.
Still, it should not take GDB anywhere near minutes to
stepornext.