From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18151 invoked by alias); 27 Aug 2010 09:41:49 -0000 Received: (qmail 18143 invoked by uid 22791); 27 Aug 2010 09:41:49 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.nokia.com (HELO mgw-mx09.nokia.com) (192.100.105.134) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 27 Aug 2010 09:41:44 +0000 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o7R9fAc1018470 for ; Fri, 27 Aug 2010 04:41:42 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Aug 2010 12:41:04 +0300 Received: from mgw-da02.ext.nokia.com ([147.243.128.26]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Aug 2010 12:41:03 +0300 Received: from gar.localnet (berwst16747.europe.nokia.com [172.25.167.47]) by mgw-da02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o7R9f1rj011460 for ; Fri, 27 Aug 2010 12:41:02 +0300 From: =?utf-8?q?Andr=C3=A9_P=C3=B6nitz?= To: gdb@sourceware.org Subject: Re: gdb breaking down at printing variable Date: Fri, 27 Aug 2010 09:41:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.32-21-generic; KDE/4.4.2; i686; ; ) References: <201008261425.21062.andre.poenitz@nokia.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201008271140.58307.andre.poenitz@nokia.com> X-Nokia-AV: Clean X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-08/txt/msg00157.txt.bz2 On Thursday 26 August 2010 22:54:58 ext Tom Tromey wrote: > >>>>> "Andr=C3=A9" =3D=3D Andr=C3=A9 P=C3=B6nitz writes: >=20 > Andr=C3=A9> This is most likely http://gcc.gnu.org/bugzilla/show_bug.cgi?= id=3D44731=20 > Andr=C3=A9> i.e. not gdb's fault. >=20 > I think there actually is a gdb bug here. gdb should be resilient even > when the inferior's memory is trashed. In my response I also said >> [...] I am pretty sure it can be triggered independently by uninitiali= zed=20 >> or corrupted data in the "real" vector object containing the same "noi= se". I do acknowledge that there are two independent issues, one gcc and=20 one gdb related. I mostly meant to say that even if gdb were not at fault Vikas Mishra's problem would still exist due to the gcc bug (and I was assuming that the problems of uninitialized data and gdb's own pretty- printers had been discussed often enough in the past to not reiterate ;-)). Andre'=20