This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

	l	<not accessible>
	m	<not accessible>
	s	<19932 items>
	stdStr	""
	stdStrRef	<not accessible>
	v	<not accessible>

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\", 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\", 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\", 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.



> andr's post in QT site
> 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]

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]