Fwd: [patch] avoid the crash of gdb+pretty printer on initialized local variables

[Martin Runge <martin.runge@web.de>]

Hello,

I have seen gdb running into very long loops on Linux, too (Ubuntu
11.04, gdb 7.2 and 7.3). It looks like gdb is frozen, but it uses 100%
CPU. When attaching to that gdb process, I observed gdb fetching a lot
of values (address increasing, but the range was by far too large). I
guess this comes from a pretty printer, asking gdb to fetch too many
values. libstdc++ and Qt4 pretty printers were in use in my case.

Although the error is probably somewhere in the pretty_printers, the
user experience is very confusing. E.g. with Eclipse CDT on top, gdb
does not respond to mi commands any more. As gdb does not give any
"progress" of "still alive" messages via mi to Eclipse, it runs into a
timeout and assumes gdb dead, debug session is broken and needs to be
restarted.

I think, only few people write their pretty printers themselves. Most
get them "somewhere from the Internet", so its hard to guarantee
quality or rely on it.

Would it be a good idea in your eyes, if

- gdb would guarantee a response time to mi commands ( limit the time
spent in a mi command -> stop fetching values when time is over)?

- gdb gave some progress reports "still working, nn% done" in regular
intervals, so mi clients like Eclipse can restart their timeout? For
Example smartcards do so. If asked for a long running operation, the
smartcard first replies by asking the terminal (== card reader) to
extend the timeout before starting work. This can be repeated as often
as neccessary to complete the operation and the terminal gets regular
feedback. The card terminal may not deny the smartcard's wish.

- some possibly long running mi commands could be aborted over mi
(those that run a loop over many small operations, like
pretty-printers)?

best regards
Martin