Re: [patch][python] 0 of 5 - Frame filters and Wrappers

[Tom Tromey <tromey@redhat.com>]

>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:

Tom> What is it that is inconsistent?

Phil> Just the naming.  With MI, because it is a machine interface, option
Phil> length is not so important.  So --no-frame-filters in the MI command
Phil> turns off a specific feature.  However, "raw" in the "bt" command
Phil> does not turn off a specific function, or is ambiguous.  I would
Phil> really like  to think of an option name that is small enough not to be
Phil> painful to type, but meaningful and specific. I could not, so I just
Phil> highlighted it in the review.

Ok, thanks.

I do think it would be useful to have an option meaning "disable value
pretty printing for this bt".  Perhaps that should be "raw" and we
should have a different name for this.  Or maybe "raw" should mean both
-- since that would truly be "raw".

Phil> Well there are two steps.  The actual filtering, this occurs when
Phil> frame filters operate on the frame iterator.  Errors can occur
Phil> here, though I suppose the scope for that is considerably narrower
Phil> than in the printing phase.  If an error occurs in this phase I think
Phil> (though the patch does not do this right now), we abandon the stack
Phil> trace with an error message of the name of the erroring filter, and
Phil> defer to GDB's inbuilt backtrace.  For both MI and CLI.  As no frames
Phil> have been printed yet, this would be fairly clear.

Filtering and printing, in most cases, have to be interleaved.
Otherwise I think there will be scaling issues.

The case where interleaving is not possible is when printing the tail
end of the stack trace: "bt -50".  Here you have to save the last N
frames somewhere before printing.

Phil> At the printing step this is a different issue.  At this point all of
Phil> the frame filters have executed. Now the Python code is printing out
Phil> the backtrace frame-by-frame with its own built-in routines according
Phil> to how each frame wrapper decorates each frame.  I think an error
Phil> with the frame wrapper as you suggested, then moving onto the next
Phil> frame is probably best here?

I tend to think just erroring out immediately is ok.
A tool like ABRT ought to send both "bt full" and "bt full raw" anyway,
to avoid these kinds of potential problems; and users can react
accordingly easily enough -- just disable the printer and repeat the
command.

Tom