Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Vladimir Prus <vladimir@codesourcery.com>
Cc: gdb@sources.redhat.com
Subject: Re: Robustifying pretty-printers
Date: Mon, 15 Jun 2009 20:01:00 -0000	[thread overview]
Message-ID: <m3zlc9467k.fsf@fleche.redhat.com> (raw)
In-Reply-To: <200906131411.34204.vladimir@codesourcery.com> (Vladimir Prus's message of "Sat\, 13 Jun 2009 14\:11\:33 +0400")

>>>>> "Vladimir" == Vladimir Prus <vladimir@codesourcery.com> writes:

Vladimir> While playing with pretty-printers and KDevelop, I've got GDB
Vladimir> to "hang", with the below backtrace:

Yeah :(

Vladimir> Now, what are the best strategies for fix this (assuming GCC
Vladimir> won't be fixed for 10 years to come)?

It will be fixed, but that won't matter, because users will still
smash the stack.

Vladimir> Alternatively, we might need to revive the code to limit the
Vladimir> number of children to fetch, and use some reasonable limit,
Vladimir> like 10. Comments?

With the current libstdc++ printers I am sure you will be able to come
up with any number of weird problems here.

A few thoughts:

* In the case of iterating over a container, the CLI code here already
  does the right thing -- it iterates over the children and respects
  "set print elements".  If the python code returns an iterable object
  (i.e., it doesn't immediately fetch all the children), then I think
  the result should be fairly sensible.  (Most libstdc++ printers do
  this, but I haven't checked them all recently.)

  So, one idea is to do as you suggest: resurrect the child-limiting
  code for MI.  This is necessary but not sufficient, because the
  previous patches did not make varobj fetch lazily.  This should not
  be very hard, though.

* We can add a new Value method to detect whether a pointer-valued
  Value is valid.  Then we could weed out some bad cases early in the
  printers.

* I'm not sure what to do about std::string.  Here, lazy iteration
  cannot fix the problem.  We could bake "print elements" awareness
  into the printer itself, but this is unsatisfactory since it can
  yield the "wrong" display to the user in some cases (string printing
  is very weird IMNSHO).  Maybe 3 times this limit or something like
  that would work well enough in most situations.  Or maybe we can
  just ignore the weird corner cases.

It would be nice if there were a way to make this magically work for
all printers without the printer authors needing to do anything
special.  I don't see how that could be done, though.

Let me know what you think.  I'm planning to fix all the known printer
problems shortly.

Tom


  parent reply	other threads:[~2009-06-15 20:01 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-13 10:11 Vladimir Prus
2009-06-13 10:21 ` Vladimir Prus
2009-06-15 12:28   ` Phil Muldoon
2009-06-15 12:39     ` Vladimir Prus
2009-06-15 12:55       ` Daniel Jacobowitz
2009-06-15 13:25         ` Vladimir Prus
2009-06-16  7:22           ` André Pönitz
2009-06-15 20:01 ` Tom Tromey [this message]
2009-06-16  8:22   ` Vladimir Prus
2009-07-07 21:48     ` Tom Tromey
2009-07-09 17:20       ` Vladimir Prus
2009-07-09 19:14         ` Tom Tromey
2009-07-10  6:13           ` Vladimir Prus
2009-07-10 16:25             ` Tom Tromey
2009-07-10 16:40               ` Vladimir Prus
2009-07-10 16:48                 ` Tom Tromey
2009-07-10 18:46                   ` Vladimir Prus
2009-07-10 18:52                     ` Tom Tromey

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=m3zlc9467k.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=gdb@sources.redhat.com \
    --cc=vladimir@codesourcery.com \
    /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