From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19582 invoked by alias); 5 Dec 2011 12:17:26 -0000 Received: (qmail 19570 invoked by uid 22791); 5 Dec 2011 12:17:24 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.nokia.com (HELO mgw-da02.nokia.com) (147.243.128.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 05 Dec 2011 12:17:09 +0000 Received: from gar.localnet (berwst16747.europe.nokia.com [172.25.167.47]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pB5CH8OA017296 for ; Mon, 5 Dec 2011 14:17:08 +0200 From: =?utf-8?q?Andr=C3=A9_P=C3=B6nitz?= To: gdb-patches@sourceware.org Subject: Re: Fwd: [patch] avoid the crash of gdb+pretty printer on initialized local variables Date: Mon, 05 Dec 2011 12:48:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-12-generic; KDE/4.6.5; i686; ; ) References: <4ED379D8.4060808@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201112051317.29098.andre.poenitz@nokia.com> X-Nokia-AV: Clean X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-12/txt/msg00130.txt.bz2 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'