This is the mail archive of the
mailing list for the Archer project.
Re: uninitialized memory, pretty printers and full backtraces
- From: Paul Pluzhnikov <ppluzhnikov at google dot com>
- To: Phil Muldoon <pmuldoon at redhat dot com>
- Cc: Project Archer <archer at sourceware dot org>
- Date: Thu, 22 Jan 2009 07:52:39 -0800
- Subject: Re: uninitialized memory, pretty printers and full backtraces
- References: <49788E35.email@example.com>
On Thu, Jan 22, 2009 at 7:18 AM, Phil Muldoon <firstname.lastname@example.org> wrote:
> I was working on another pretty printing task, when I noted the behaviour
> below. I'm not sure how to fix it. Thought it worth discussing here.
> The basic premise is that in a "bt full" condition, the pretty printers
> appear to try and grok (and pretty print) all local variables in a frame -
> even if they are not initialized at the time the "bt full" was requested. I
> believe this is not so different from existing GDB behaviour. But with the
> Python pretty printers, the problem is magnified as the printers will
> attempt to read, and interpret assorted random memory addresses in an
> uninitialized class.
I've seen that as well, thanks for bringing this up.
One possible way to fix this is to fall back to "raw print" if the python
pretty printer throws exception.
This will make it harder to debug python pretty-printers themselves:
it would make it appear that they are not "firing" if there is a problem
with python code. But perhaps logging exception only when "set verbose on"
is in effect is sufficient to overcome this.