From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7181 invoked by alias); 2 Aug 2010 07:40:44 -0000 Received: (qmail 7165 invoked by uid 48); 2 Aug 2010 07:40:44 -0000 Date: Mon, 02 Aug 2010 07:40:00 -0000 From: "jens dot elmenthaler at verigy dot com" To: gdb-prs@sourceware.org Message-ID: <20100802074043.11868.jens.elmenthaler@verigy.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug varobj/11868] New: Don't call pretty printers for local variables that are not yet constructed X-Bugzilla-Reason: CC 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: 2010-q3/txt/msg00140.txt.bz2 I have enabled the python pretty printers for varobjs (-var-enable-pretty- printing in the beginning of the MI session). If running into breakpoints at the first line of a method that contains local variables of a non-trivial type, I run into all types of errors, ranging from python exceptions to "Cannot access memory at address ...". The reason is that their constructor is called in a soure line behind the breakpoint, such that data members are not yet initialized. In many cases (consider a collection with pointer members "start" and "end"), a large amount of garbage data is read (unnecessary response time), that might even be unaccessible (unnecessary errors). My gdb frontend (Eclipse DSF GDB) does not actually crash or hang. It's just that running the python pretty printer on tons of unitiliazed data with all those errors really is a usability problem for frontends that use the varobjs. I don't think the writers of a python pretty printer have the chance to workaround, nor do I think they should. I know the argument that the pretty printer also has to work in case of a programming error in C/C++ code. But I don't think a user should suffer is debugged code as well as the provided pretty printers are clean. As far I as know, the debug info generated by gcc provides the information in which line a local variable is constructed. -- Summary: Don't call pretty printers for local variables that are not yet constructed Product: gdb Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: varobj AssignedTo: unassigned at sourceware dot org ReportedBy: jens dot elmenthaler at verigy dot com CC: gdb-prs at sourceware dot org http://sourceware.org/bugzilla/show_bug.cgi?id=11868 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.