A Couple of GDB Tricks

What is life without debugging?… :roll:

Getting to know the GNU Debugger can give you lots of power and speed. Unfortunately if you’re working on a big project such as KDE, using it is not always pleasant.

By default, GDB loads the “symbols” from the libraries used by the debugged application. If it wouldn’t do that, it couldn’t tell you the names of classes / functions / variables. When your application uses Qt however, these libraries are huge and can easily eat up 512MB of RAM in debugging symbols. That means that if you don’t have a lot of memory, each time you’ll run your app in the debugger, your machine will start to whirr and thrash. Swap space will be used and performance will go down dramatically.

Fortunately there’s a way around this problem. Robert Knight of Konsole fame shared this on the kde-devel mailing list. The trick is to tell GDB not to load the symbols automatically before telling it to run your application.

set auto-solib-add off

This means that your backtraces will be full of ???s. Notice which libraries your program calls and load them manually with a command like

shar QtGui

This will load all libraries containing QtGui in their names. Don’t try shar Qt as it will load the entire Qt, which we were trying to avoid in the first place.

After loading a library manually, issue the backtrace (bt) command again, notice and load the next library, and so on until you have a full call stack. Now check your memory usage. Relieved? ;)

Many times, however, you may want to attach GDB to an already running process. When you do this (using gdb app-name app-PID), GDB doesn’t give you a chance to stop it from loading the symbols. One way around this is to add the

set auto-solib-add off

line to your ~/.gdbinit file. That means GDB will never load symbols by default. You can return to the old behavior by issuing set auto-solib-add on at any time.

4 Responses to A Couple of GDB Tricks

  1. Constantin says:

    There is a great article by Robert Knight here, to further simplify your debugging experience.

  2. St Louis Malpractice says:

    “When your application uses Qt however, these libraries are huge and can easily eat up 512MB of RAM in debugging symbols. That means that if you don’t have a lot of memory, each time you’ll run your app in the debugger, your machine will start to whirr and thrash. Swap space will be used and performance will go down dramatically.”

    Does anyone still run any system with just 512 of ram.? Is this still a problem with more memory? like 2 gig.

  3. Constantin says:

    You should be fine without these tricks if you have enough memory.

    • Scott Salley says:

      Even now in 2010, not all systems have lots of RAM. In addition to the direct costs of RAM (the amount you pay for the chips), there are indirect costs. RAM requires power which can significantly affect battery life (which is why so many cell phones have limited RAM) or the size of a wall wart (transformer) required, and the increased power usage also means increased heat output.

%d bloggers like this: