This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Robustifying pretty-printers


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]