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

[Tom Tromey <tromey at redhat dot com>]

>>>>> ">" == Asm gmail <asmwarrior@gmail.com> writes:

>>  Hi, I still get gdb crashed when showing local variables.

>> stdStr = 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)
>> OverflowError: long int too large to convert to int

Interesting.  Maybe a bug in valpy_lazy_string.
Could you file this as a bug report?

>> m = std::map with 2009251885 elementsTraceback (most recent call last):
>> File "D:\code\mingw451tdm\bin\libstdcxx\v6\printers.py", line 353, in next
>> n = self.rbiter.next()
>> 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.

I am going to guess g++ bug here, but I don't know for sure.
ISTR an open bug where sometimes g++ erroneously emits "void *".

>> stdStrRef =
>> s = std::stack wrapping: std::deque with -521291805 elements = {<error
>> reading variable s (Cannot access memory at address 0x80)>

I am working on a fix for this.

Currently all gdb exceptions are convert to a Python RuntimeError.  But,
I think we should differentiate a little more.  In particular, I think a
gdb MEMORY_ERROR should be a separate class, and should be handled
specially by the pretty-printing code (basically by omitting the stack
trace).

I think this, along with the default settings for limiting array and
string print sizes, should solve most cases of "corrupt data makes gdb
barf all over".

>> 3. gdb bugzilla
>> http://sourceware.org/bugzilla/show_bug.cgi?id=11407

I think this bug was specifically about errors causing the backtrace to
stop too early.

Please file bug reports when you run across oddities like these.
Although it sometimes takes a while, we do try to address them all.

Tom