Re: Robustifying pretty-printers

Tom Tromey
2009-06-15T20:01:34Z

>>>>> "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