public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "jens dot elmenthaler at verigy dot com" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug varobj/11868] New: Don't call pretty printers for local variables that are not yet constructed
Date: Mon, 02 Aug 2010 07:40:00 -0000	[thread overview]
Message-ID: <20100802074043.11868.jens.elmenthaler@verigy.com> (raw)

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.


             reply	other threads:[~2010-08-02  7:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-02  7:40 jens dot elmenthaler at verigy dot com [this message]
2010-08-02 13:37 ` [Bug varobj/11868] " marc dot khouzam at ericsson dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100802074043.11868.jens.elmenthaler@verigy.com \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).