Creator causes gdb to take way too much memory on Arch Linux and Ubuntu

Reported as an Arch bug just in case: https://bugs.archlinux.org/task/57924

Description:

As a Qt developer and maintainer of Qt Quick (developing Qt itself, not just apps), I often need to use debug builds of Qt, trace execution, debug crashes etc. I use Qt Creator for this, and it in turn uses a gdb session. For some reason, nowadays it takes many gigabytes of RAM (e.g. 6-8GB on different occasions) to load up all the debug symbols in gdb, before the process can even start running. This does not happen when I use gdb on the command line, only the way that Creator uses it. So it may be that Creator uses some sort of gdb command which makes it behave as a memory hog. But the only people noticing this issue are Arch Linux users: so it doesn't have very high visibility within the company, and I don't know if there is some relatively recent change in Creator that may have caused it (although it's been going on for at least a couple of months if not longer), or it's a gdb bug, or lack of optimization, or what. I have gdb 8.1 now, but have also tried downgrading to gdb 7.12.1; it didn't help. The result is that I can only use machines which have lots of memory and still have to be very careful not to run anything else while debugging Qt, because 12GB of RAM is the bare minimum to do that now, to hold gdb + Creator + X11 all at the same time; and it has to be a fresh enough Creator session that Creator hasn't yet turned into too much of a hog itself. It's hopeless on my 4GB laptop; 8GB wouldn't be enough either. I think that's excessive.

I usually configure Qt something like this:

mkdir ~/dev/qt5-dbg; cd ~/dev/qt5-dbg
../qt5/configure -developer-build -debug -nomake examples -nomake tests -opensource -confirm-license -no-icu -no-tslib -no-pch
make (I use icecc and ccache, that's why -no-pch is useful)

Steps to reproduce:

• build Qt from git
• open any Qt Quick example or application in Qt Creator
• build the example with the local Qt build
• try to debug it
• observe memory usage with top in another shell
• be prepared to kill gdb before your system crawls to a halt