This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Hangs in GDB auto-complete
On 2010-11-16 18:20, Tom Tromey wrote:
Kristoffer> After I upgraded my Ubuntu system to Lucid Lynx (10.04)
What version of gdb?
gdb --version
GNU gdb (GDB) 7.1-ubuntu
Kristoffer> It's very irritating, especially when I end up having to
Kristoffer> kill GDB.
You should be able to C-c out of any completion.
If you can't, then that is a gdb bug.
Well, I can't C-c. I'm stuck in one of these right now, in fact; it's
been locked up for 2-3 minutes now, at 148 % CPU according to top:
7563 krsj 20 0 184m 169m 67m R 148 8.5 5:55.72 gdb
Oh, wait! My C-c went through after 2 minutes! As I said, they're not
infinite lockups, but for practical purposes they may as well be sometimes.
This lockup happened when I typed
(gdb) p m_evaluator.m_lastWitness
...which isn't even an auto-complete, but just a symbol lookup. This
particular one should work, too; it's not a typo. I'll try it again
without C-c to see if it does find the symbol eventually...
The executable in question is attached while running, not started by
gdb, but another smaller project I am working on suffers from the same
problem while being started the usual way.
Kristoffer> I've no notion of the inner workings of GDB and no idea what
Kristoffer> this is all due to, but perhaps someone here has some clue?
We need more details, ideally enough to try to reproduce the problem.
It could be any number of things, depending on the details of what you
are doing.
I'll see if I can find some method in the madness. Pretty sure it's got
nothing to do with the code I'm debugging but with my system and the way
gdb is configured somehow. (I haven't deliberately modded gdb in any
way, I hasten to add.)
There, the print command went through finally:
(gdb) p m_evaluator.m_lastWitness
$111 = {point1 = {x = 0.095000000000000001, y = 0.044999999999999998, z
= 1}, point2 = {x = 0.095000000000000001, y = 0.044999999999999998, z =
1.2599999713897705},
distance = 0.25999997138977049, typeOnA = spatial::WITNESS_FACE,
typeOnB = spatial::WITNESS_VERTEX, idOnA = 0, idOnB = 4, paramOnA = 0,
paramOnB = 7.5651897269402635e-306,
normal = {x = 0, y = 0, z = 1}}
I sure would like to be able to query variables reliably in less than
three minutes, though...
I'll see what I can do about setting up a repro case.
Kristoffer