Re: About the "info locals" command of gdb and python pretty printer

[asmwarrior <asmwarrior at gmail dot com>]

On 2010-6-22 4:08, Tom Tromey wrote:
> > > At this time, if we run the "info locals" with python stl pretty
> > > printer enabled, as you see, if you breakpoint is still at the first
> > > line "int aaa = 1;", then bbbb and cccc are not initialized, this may
> > > cause the python script to plot random values, some times, gdb or
> > > python will get crashed.
> > >        
> I think the real problem here is that gdb crashed.  That should not
> happen.  Can you find out what went wrong?
>
> Python exceptions are "normal" in the sense that they should not cause
> gdb any problems.
>
> We should fix the problem that exceptions during pretty-printing can
> cause problems.  I think there are a few parts to this.  We
> should differentiate the different types of gdb exception in Python, so
> that things like memory errors can cause nicer behavior.  We should also
> make lazy strings truly lazy during printing.  This will eliminate some
> problems when trying to print a lazy string with length==-1.
>
> Tom
>    
Hi, Tom, thanks for your reply. I also noticed your reply in
http://sourceware.org/bugzilla/show_bug.cgi?id=11407#c34
As you said, GDB should be robust, so that even it has some exceptions 
from python. (Or python script will call internally some gdb command, at 
that time, gdb has some exception too).

I'm not sure how to get a "stack track" when gdb crashed. Do I need to 
run GDB under GDB. So, the debuggee GDB get crashed, the debugger GDB 
can generate some stack trace inforamtion?

Thanks

Asmwarrior