This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Robustifying pretty-printers
On Tuesday 16 June 2009 Tom Tromey wrote:
> >>>>> "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.
Yeah.
> 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.
Exactly, they only limited the number of children sent to frontend. If we
go this route, I think it is better to make -var-list-children take a
couple of parameters to specify the desired range, with [0, whatever] as
default -- as opposed to the previous approach where this limit should
be set on varobj, not on individual -var-list-children call.
It's also obvious to you, but for everybody's benefit I'd point out that
-var-list-children some_var 10 20
will fetch the [0, 10] range if not already fetched, which is probably
just fine, given how frontend is likely to use this functionality.
> 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.
Is this substantially better than letting pretty printer throw? What
will happen in that case -- I assume the value will end up ""?
> * 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
How "wrong" exactly?
> 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.
Can the .string method automatically trim at 'print elements' value,
or thice it? But, it's not clear what to do if user wants to fetch
more of the value.
- Volodya