This is the mail archive of the mailing list for the Archer 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]

[patch] PR python/10344

With GDB, when an inferior stops at a breakpoint (and the stock printing options are unchanged), GDB attempts to print out the function name and the arguments of the frame. If any of these argument values triggers a Python pretty-printer, then the pretty-printer supplies the output format for printing that argument. While the breakpoint frame printing code uses three uiout levels to construct the function and argument output, if the argument pretty-printer calls parse_and_eval, a further two uiout levels are consumed while the expression is evaluated. In this particular case, the parse_and_eval call creates an inferior function call to an inferior function which raises a SIGSEGV. GDB catches this and tries to report the issue in the inferior function call. As there are no further levels for error output (MAX_UI_OUT_LEVELS = 6}, and (especially in this PR) if a GDB exception is created it cannot be printed and GDB raises an internal error.

I decided to investigate this case on the mailing list, and the historical cases for fixing uiout level overflow is either to improve the cleanups or just to increment the maximum when cleanups are correct. I checked all the cleanups, and all the levels are required at the time they are in use. It goes something like this:

-> print frame -- 1st level
---> print arguments -- 2rd level
------> loop through individual arguments, use and disregard another level per argument in the list -- 3rd level
---------> One argument has a pretty printer that calls parse_and_eval that consumes 2 more levels. -- 5th level
------------> parse_and_eval calls an inferior function which raises a signal. Try to report the failure. Out of levels. Raise internal error

As a second thought I looked at how difficult it would be to make the uiout level grow and shrink dynamically. I noted however that uiout levels are allocated on the stack, while the streams associated with them are lazily malloc'ed when needed (in fact the programmer need do this manually, and clean them up too). I had second thoughts on this when I counted the number of times pop and push_level are called in a random debugging session. It was in the 1000s (if not 10,000s can't remember). That would be a lot of mallocs and frees :( So I decided to leave the uiout levels, at least, allocated on the stack at a fixed level.

The only thing I can think to do in this case is just to add one more level to the maximum uiout levels. I am not sure why the initial level is set at such a small level. The uiout level struct is not particularly large. Anyway, what do you think? This fixes the PR.


2009-09-23 Phil Muldoon <>

PR python/10344

* ui-out.c (MAX_UI_OUT_LEVELS): Increment to 7.


diff --git a/gdb/ui-out.c b/gdb/ui-out.c
index 19a4644..0224d70 100644
--- a/gdb/ui-out.c
+++ b/gdb/ui-out.c
@@ -44,7 +44,7 @@ struct ui_out_hdr
    is always available.  Stack/nested level 0 is reserved for the
    top-level result. */

-enum { MAX_UI_OUT_LEVELS = 6 };
+enum { MAX_UI_OUT_LEVELS = 7 };

 struct ui_out_level

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