From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13579 invoked by alias); 5 Dec 2011 10:13:42 -0000 Received: (qmail 13560 invoked by uid 22791); 5 Dec 2011 10:13:40 -0000 X-SWARE-Spam-Status: No, hits=-0.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-iy0-f169.google.com (HELO mail-iy0-f169.google.com) (209.85.210.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 05 Dec 2011 10:13:26 +0000 Received: by iapp10 with SMTP id p10so6375548iap.0 for ; Mon, 05 Dec 2011 02:13:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.43.65.79 with SMTP id xl15mr9250550icb.6.1323080005742; Mon, 05 Dec 2011 02:13:25 -0800 (PST) Received: by 10.42.175.8 with HTTP; Mon, 5 Dec 2011 02:13:25 -0800 (PST) In-Reply-To: References: <4ED379D8.4060808@gmail.com> <4ED8534D.2050100@gmail.com> <4EDAD0B3.80505@gmail.com> Date: Mon, 05 Dec 2011 10:13:00 -0000 Message-ID: Subject: Fwd: [patch] avoid the crash of gdb+pretty printer on initialized local variables From: Martin Runge To: gdb-patches@sourceware.org Cc: asmwarrior , Tom Tromey Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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/msg00117.txt.bz2 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.=C2=A0libstdc++ 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 (=3D=3D 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