This is the mail archive of the
mailing list for the GDB project.
Re: Fwd: [patch] avoid the crash of gdb+pretty printer on initialized local variables
- From: AndrÃ PÃnitz <andre dot poenitz at nokia dot com>
- To: gdb-patches at sourceware dot org
- Date: Mon, 5 Dec 2011 13:17:29 +0100
- Subject: Re: Fwd: [patch] avoid the crash of gdb+pretty printer on initialized local variables
- References: <4ED379D8.firstname.lastname@example.org> <CAF4KFGp2cDOzKdV62MfX0vpHUAxj1D2W0W3cBZnZpYHPYxZEuA@mail.gmail.com> <CAF4KFGoXAo-+0xvUFp-7_4Uj5RKGc1_39wRkTS+U6_kM8oYeEw@mail.gmail.com>
On Monday 05 December 2011 11:13:25 ext Martin Runge wrote:
> 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
> 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
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