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

["André Pönitz" <andre.poenitz@nokia.com>]

On Monday 05 December 2011 11:13:25 ext Martin Runge wrote:
> 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.

[Even "good" pretty printers have a hard time to work robustly on 
uninitialized data without being too restrictive.]

> 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)?

I think it would be sufficient if a frontend could interrupt a running python
script, see http://sourceware.org/bugzilla/show_bug.cgi?id=12615

Andre'