[Bug python/10344] Pretty printers that call into inferior could crash GDB

["pmuldoon at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From pmuldoon at redhat dot com  2009-09-22 19:47 -------
I looked at this today, and this is what I believe is occurring. The test
environment:

gdb -q -ex 'set prompt (top) ' -ex run  --args archer-new/build/gdb/gdb -ex
'source t.py' -ex 'break bar' -ex run ./a.out

This stops GDB at the bar () function. When GDB  stops at a breakpoint, as part
of the breakpoint descriptive text it attempts to print out the function name
and arguments via: print_frame_info in stack.c. As part of this function and the
child functions that it calls,  the uiout->level is incremented three times (via
successive calls to make_cleanup_ui_out_tuple_begin_end which calls
ui_out_begin, which among other things calls push_level). At this point the
uiout->level is now 3.

Because arguments are values, each argument is run by the pretty printer code.
As Foo (the argument to bar) has a pretty-printer registered to it, that python
pretty printer is called. This call to a pretty printer additionally consumes
two more uiout->levels. The level is now 5.

Normally all of these levels are properly cleaned up and released. But we are
still progressing through the original call. Anyway ....

It just so happens that the pretty printer via parse_and_evals calls a function
that results in sigsegv. GDB tries to report this via error() but as that
consumes yet another level, (now 6) it triggers the overflow assert as detailed
in the previous comment.

Some thoughts on fixes:

1) Increase the uiout levels maximum. I've looked at the code and it seems to be
an arbitrary amount of levels. Why 6? It seems quite low, especially in
recursive situations like this. The problem with this is, how do we guarantee
that a more intensive recursive test case would not trigger it?

2) Rewrite uiout to really function like a stack (That grows and shrinks as
demands indicate), that the comments in the uiout seems to think it should?

3) Add a reserved channel for error streams that will always guarantee an error
is printed. This would seem ok, except it won't actually solve the issue (but
will guarantee that GDB can tell us

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10344

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.