Compile #include <string> struct QString { static inline QString fromStdString(const std::string &); }; int main() { std::string str; } using g++ -g. Then run ~/bin/gdb-7.0 -ex 'b main' -ex r -i mi --args ./a.out debug Typing -stack-list-locals 2 results in ^done,locals=[{name="str",type="QString::string"}] Note the bogus 'type' field. Removing the "QString::fromStdString()" and repeating the procedure yields ^done,locals=[{name="str",type="string"}] as does gdb 6.8 in both scenarios.
It's not 100% reproducible. Every now and then I get the correct answer "std::string", but in most cases it's "QString::string". This is stock ubuntu 9.04 with gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3 here. Archer version is dad6b53fe4a6df586dcd0a57e2151e7663191f18, the 7.0 case is using a build from an unmodified source package of the gdb 7.0 release.
FWIW, I couldn't reproduce this at all on my F11 box. I ran gdb under valgrind, on the off chance that this would show a latent bug, but that didn't report one either. It is possible that this is something that was fixed by one of the dwarf2read.c allocation bug fixes; could you try CVS HEAD?
Andre, I believe the ball is yours. Are you planning to recheck this?
Thanks for reminding me. The problem is still reproducible with current git master and released 7.1. However, I had to go back to gcc 4.2.4 to reproduce it (even the updated Ubuntu 9.04 gcc 4.3 is fine), so this pretty much looks more like a gcc issue than a gdb issue, and it's even one that is fixed there by now. I doubt gdb is interested in working around old gcc issues, so I guess this issue can be closed.