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

asmwarrior asmwarrior@gmail.com
Wed Jun 23 12:23:00 GMT 2010

Hi, I have two things to say: (it is both related to python pretty 
printer and the gdb, so I send it to both mail lists, sorry for the 

1, It seems the current SVN std python script didn't works any more. So, 
this my be a regression.

It seems there is a commit in
Revision: 161233
Author: doko
2010-06-22  Matthias Klose  <doko@ubuntu.com>

         * python/libstdcxx/v6/printers.py: Don't use string exceptions.
Modified : /trunk/libstdc++-v3/ChangeLog
Modified : /trunk/libstdc++-v3/python/libstdcxx/v6/printers.py

But I found that this revision didn't work any more, I try to print out 
some vector, list. (I have tested under Windows XP, MinGW 4.5 and MinGW 
4.4.4, GDB cvs 20100623)

All the response from gdb just gives the same as print /r XXXX.

2, @tom

On 3:59, Tom Tromey wrote:
 >>>>>> ">" == Asm gmail<asmwarrior@gmail.com>  writes:
 >>> 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

Today, I have build  gdb-cvs-20100623 , and try to make gdb crash on 
printing some uninitialized stl containers by pretty printers. But it 
stands through all the cases, so, it seems the gdb-cvs-20100623 is quite 
stable than the gdb-cvs-20100619. I'm not sure what has changed. It 
seems it more stable now.

By the way, I will report if it crashed again.


Asmwarrior ollydbg from codeblocks' forum.

More information about the Libstdc++ mailing list