Re: gdb with python support still get crash on showing uninitialized local variables

[Andrà PÃnitz <andre dot poenitz at nokia dot com>]

Hi.

I'll take that direct CC: to me as a hint that I should comment. Not sure 
this is a good idea, but here we go:

On Thursday 14 October 2010 04:12:16 ext asmwarrior wrote:
>   Hi, I still get gdb crashed when showing local variables. Here is the
> test code:
> 
> OS: windows xp
> GDB: clean gdb cvs snapshot weekly 2010 10 12 build with python support
> GCC: TDM-MinGW GCC 4.5.1
> so, the program is build with -g (by default, it use the dwarf-2 format,
> I have just tested by using -gdwarf-3, there's the same crash)
> 
> it seems gdb crashed when trying to show the vector :
> std::vector<std::string> v = {"a", "b", "c"}; , this is an uninitialized
> variable.
> 
> Tested under codeblocks IDE

Works fine for me using Qt Creator on Linux, gdb 7.1, 7.2 and recent CVS,
including (our non-gdb) Python based pretty printing.

Output in the Locals&Watchers view is something like

Locals	
	l	<not accessible>
	m	<not accessible>
	s	<19932 items>
	stdStr	""
	stdStrRef	<not accessible>
	v	<not accessible>
	wxStr	
	wxStrRef	
Watchers	

Not nice, but it's uninitialized data after all, and a stack could possibly have 
19932 items. 

So I think the problem is neither the uninitialized data, nor Python, nor gdb's
use of Python in general.

> File "D:\code\mingw451tdm\bin\libstdcxx\v6\printers.py", line 297, in next
> if node.dereference()['_M_right']:
> RuntimeError: Attempt to dereference a generic pointer.
> stdStrRef =
> s = std::stack wrapping: std::deque with -521291805 elements = {<error
> reading variable s (Cannot access memory at address 0x80)>
> wxStr = UnicodeEncodeError: 'gbk' codec can't encode character u'\uffff'
> in position 0: illegal multibyte sequence
> wxStrRef = @0x40b9c6
> l = std::list = {
> [0] = <error reading variable l (Cannot access memory at address
> 0x50000069)>
> v = std::vector of length -37952, capacity -519864265 = {Traceback (most
> recent call last):
> File "D:\code\mingw451tdm\bin\libstdcxx\v6\printers.py", line 549, in
> to_string
> return self.val['_M_dataplus']['_M_p'].lazy_string (length = len)
> RuntimeError: Cannot access memory at address 0x90000cb6
> , Traceback (most recent call last):
> File "D:\code\mingw451tdm\bin\libstdcxx\v6\printers.py", line 549, in
> to_string
> return self.val['_M_dataplus']['_M_p'].lazy_string (length = len)
> RuntimeError: Cannot access memory at address 0x90909084
> , Traceback (most recent call last):

This looks like gdb's own pretty printers could make more use of
try/except and perhaps a few sanity checks on the contents.
Printing "std::vector of length -37952" does not make much sense.

Andre'

PS:

> andr's post in QT site
> http://labs.qt.nokia.com/2009/06/22/peek-and-poke/#comment-4269
> 
> Itâs ânot readyâ yet. The gdb python âpretty-printersâ have serious
> problems with uninitialized and/or damaged C++ objects. I understand
> work to fix that is going on, but from my point of view it is not ready
> for shipping yet.

That's over a year old, and has significantly changed in so far as Qt Creator
nowadays uses gdb's Python extensively to do pretty printing. Since 7.0.1
this is really good and usable. However, I do not use the gdb version of the
pretty printers for the stability reason you just encountered, and because they
cannot (easily...) create several layers including possibly "virtual" ones that
do not correspond to actual objects on the inferior side. [And then there are
non-gdb related reasons, like that I need a C++ version of the same code for
Apple's gdb/Mac (no Python there) and CDB on Windows (completely different
beast) and it's easier to keep that in sync if it's structurally similar]