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
next prev 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