From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19739 invoked by alias); 10 Nov 2011 21:48:10 -0000 Received: (qmail 19716 invoked by uid 22791); 10 Nov 2011 21:48:09 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 10 Nov 2011 21:47:57 +0000 From: "tromey at redhat dot com" To: gdb-prs@sourceware.org Subject: [Bug varobj/11868] Don't call pretty printers for local variables that are not yet constructed Date: Thu, 10 Nov 2011 21:48:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: varobj X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: tromey at redhat dot com X-Bugzilla-Status: WAITING X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: 7.1 X-Bugzilla-Changed-Fields: Status Last reconfirmed CC Ever Confirmed Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org X-SW-Source: 2011-q4/txt/msg00304.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=11868 Tom Tromey changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |WAITING Last reconfirmed| |2011-11-10 CC| |tromey at redhat dot com Ever Confirmed|0 |1 --- Comment #1 from Tom Tromey 2011-11-10 21:47:54 UTC --- We changed how errors are propagated from printers to varobj, which should help this problem a bit -- you should get a more sensible display from properly written printers. Could you try this? FWIW, I think trying to circumvent pretty-printing based on checking line numbers to see if initialization has occurred is likely to be fragile. First, in the presence of optimization, this information is not really reliable. Second, the same effect can be seen via data corruption anyway -- so it is better instead to try to come up with a solution that is robust in the presence of errors. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.