I've build gdb 7.1 on Centos 5.4 x86_64 using the system compiler. I'm trying to debug a c++ application and moved to 7.1 to get past issues in 6.8. However, when I stop and try to print an expression, it literally takes minutes for gdb to come back with the answer on a 4 core 3GHz server. A snapshot is below. The vector below is standard stl vector and tokenOffset is just a struct. I C-c'd it after 3 minutes. It will eventually print the right answer, but it takes a ridiculous amount of time. 6.8 and 7.0.1 work as expected on the same debug binaries. I built 7.0.1 out of the box as well as 7.1. 6.8 is the system gdb. 537 vector<tokenOffset> toks; (gdb) 539 unsigned prev_type = TOK_WHITESPACE; (gdb) p toks.size() Quit (gdb) show ver verbose version (gdb) show version GNU gdb (GDB) 7.1 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. (gdb)
This might be the same issue as: http://sourceware.org/bugzilla/show_bug.cgi?id=11408 could you try with this patch: http://sourceware.org/bugzilla/attachment.cgi?id=4674&action=view
(In reply to comment #1) > This might be the same issue as: > http://sourceware.org/bugzilla/show_bug.cgi?id=11408 > could you try with this patch: > http://sourceware.org/bugzilla/attachment.cgi?id=4674&action=view bug11408 should already be fixed if I check out the latest gdb sources from 7.1 branch, right (done today)? At least I found a ChangeLog saying this. The sluggishness while stepping seems to be gone, but inserting a break point is still damn slow.
Okay looks like this is a different bug then. Would you be able to make a small testcase to reproduce this ? If not, could you get a stack trace of gdb while it is hung
Created attachment 4757 [details] Stack trace while gdb is busy inserting breakpoint Here is the stack trace. I will try to create an example.
(In reply to comment #1) > This might be the same issue as: > http://sourceware.org/bugzilla/show_bug.cgi?id=11408 > > could you try with this patch: > http://sourceware.org/bugzilla/attachment.cgi?id=4674&action=view The patch appears to fix my problem. Thanks!
(In reply to comment #4) > Created an attachment (id=4757) > Stack trace while gdb is busy inserting breakpoint > > Here is the stack trace. I will try to create an example. This looks like: http://sourceware.org/ml/gdb-patches/2010-04/msg00466.html It would be interesting to know if that patch helps.
(In reply to comment #6) > (In reply to comment #4) > > Created an attachment (id=4757) > > Stack trace while gdb is busy inserting breakpoint > > > > Here is the stack trace. I will try to create an example. > This looks like: > http://sourceware.org/ml/gdb-patches/2010-04/msg00466.html > It would be interesting to know if that patch helps. Yes, it helps. I had about 4000 partial symbol tables, and the line breakpoints used absolute paths.
I am unassigning this bug since the lookup problem is fixed. It can be closed when the stat issued is fixed.
I think this was fixed ages ago.