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

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

[asmwarrior]

  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
Just set a break-point in the first statement of main().
-----------------------------------------------------------------------------------------------
#include <wx/wx.h>
#include <string>
#include <map>
#include <list>
#include <stack>
#include <vector>

int main()
{
wxString wxStr(L"wxString"); // ********set a break-point here *******
wxStr += L" Value";
std::string stdStr("std::string");
stdStr.append(" value");
std::map<int, std::string> m;
m[0] = "000";
m[1] = "111";
wxString& wxStrRef = wxStr;
wxStrRef += L" Ref";
std::string& stdStrRef = stdStr;
stdStrRef += " Ref";

std::list<std::string> l = {"a", "b", "c"};
std::vector<std::string> v = {"a", "b", "c"};

std::stack<std::string> s;
s.push("a");
s.push("b");

return 0;
}
---------------------------------------------------------------------------------------------------

Here is the full debugger log :

---------------------------------------------------------------------------------------------------
Command-line: D:\code\mingw451tdm\bin\gdb.exe -nx -fullname -quiet -args 
bin/cmd.exe
Working dir : F:\cb\test_code\gdbpython-demo\
 > set prompt >>>>>>cb_gdb:
Reading symbols from F:\cb\test_code\gdbpython-demo/bin/cmd.exe...done.
(gdb) >>>>>>cb_gdb:
 > show version
GNU gdb (GDB) 7.2.50.20101012
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
 >>>>>>cb_gdb:
 > set confirm off
 >>>>>>cb_gdb:
 > set width 0
 >>>>>>cb_gdb:
 > set height 0
 >>>>>>cb_gdb:
 > set breakpoint pending on
 >>>>>>cb_gdb:
 > set print asm-demangle on
 >>>>>>cb_gdb:
 > set unwindonsignal on
 >>>>>>cb_gdb:
 > set debugevents on
 >>>>>>cb_gdb:
 > set new-console on
 >>>>>>cb_gdb:
 > set disassembly-flavor intel
 >>>>>>cb_gdb:
 > catch throw
Catchpoint 1 (throw)
 >>>>>>cb_gdb:
 > source F:\cb\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
 >>>>>>cb_gdb:
 > source D:\code\mingw451tdm\bin\stl.gdb
source D:\code\mingw451tdm\bin\wx.gdb

 >>>>>>cb_gdb:>>>>>>cb_gdb:>>>>>>cb_gdb:
 > directory F:/cb/test_code/gdbpython-demo/
 >>>>>>cb_gdb:
 > break "F:/cb/test_code/gdbpython-demo/main.cpp:10"
Breakpoint 2 at 0x4013d3: file F:\cb\test_code\gdbpython-demo\main.cpp, 
line 10.
 >>>>>>cb_gdb:
 > run
gdb: windows_init_thread_list
[New Thread 2128.0x55c]
Breakpoint 2, main () at F:\cb\test_code\gdbpython-demo\main.cpp:10
\x1a\x1aF:\cb\test_code\gdbpython-demo\main.cpp:10:126:beg:0x4013d3
 >>>>>>cb_gdb:
 > set debugevents off
 >>>>>>cb_gdb:
 > info locals
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
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.
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):
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 0xe77d74
, 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 0x458b0e68
, 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 0x78b0ffcc
, 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 0xe7fffff9
, 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 0xfff91191
, 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 0x909090b7
, 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 0xffffff84
, 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 0xf3
, 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 0x96ff2ef4
, 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 0x70
, 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 0x96fed2f4
, 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 0x96fee670
, 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 0x6c745270
, 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 0x657a6947
, 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 0x7061653c
, 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 0x6c7451f4
, 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 0x657a6947
, 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 0x7061653c
, 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 0xcccccbf4
, 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 0x90ccccc0
, 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):
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 0x8868205e
, 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 0xe87c96f4
, 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 0xfff9e930
, 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 0x8908757f
, 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 0x45c6d869
, 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 0x46f600db
, 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 0xe740107
, 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 0x560c75f3
, 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 0xffaf99dc
, 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 0xb6e9f3
, 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 0xff32fff4
, 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 0x89e07d7d
, 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 0xdb33fc71
, 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 0xfc5d8937
, 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 0x9700a05c
, 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 0x37e85670
, 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 0x84fffa26
, 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 0x890575b4
, 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 0x3bebe071
, 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 0xd10467f
, 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 0xffffff4
, 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 0x840c44fd
, 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 0x11750c51
, 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 0x578b6f3
, 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 0x16e7fff4
, 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 0x88fff904
, , Traceback (most recent call last):
File "D:\code\mingw451tdm\bin\libstdcxx\v6\printers.py", li
ne 549, in to_string
return self.val['_M_dataplus']['_M_p'].lazy_string (length = len)
RuntimeError: Cannot access memory at address 0xe8565700
, 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 0xffffe5e4
, 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 0x560c75f3
, 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 0xfc61f3dc
, 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 0xe04589f3
, 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 0xe7e85647
, 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 0x89ffffcc
, 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 0x48ebfc71
, 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):
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 0xec458b84
, 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 0x8b007f
, 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 0x33dc457d
, 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 0x90c340b4
, 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):
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 0x64e8657f
, 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 0x1895
, 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 0xd44588f4
, 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 0xbf48881
, 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 0x458afff4
, 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 0x640189d0
, 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 0x1895
, 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 0x89f08af4
, 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 0x31ffd069
, 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 0xf9f5dddc
, 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 0x344689f3
, 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 0xfc6577
, 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 0xfffc4d77
, 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 0x10dc
, 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 0xe0458af4
, 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 0xf9e89edc
, Traceback (most recent call last):
File "D:\code\mingw451tdm\bin\libstdcxx\v6\printers.py", line 549, in 
to_string
This application has requested the Runtime to terminate it in an unusual 
way.
Please contact the application's support team for more information.
return self.val['_M_dataplus']['_M_p'].lazy_string (length = len)
RuntimeError: Cannot access memory at address 0x8c2f3
, 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):
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 0xe77d8084
, 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)
Run

---------------------------------------------------------------------------


So, it seems this problem still exist.



Here are some reference:

1.
andr's reply of my original post in gdb maillist
http://sourceware.org/ml/gdb/2010-06/msg00082.html

2.
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.

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

The bug seems been fixed, but I think it still exists.




Asmwarrior
ollydbg from Codeblocks' forum

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

[André Pönitz]

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]

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

[asmwarrior]

  thanks for the reply.

On 2010-10-15 2:29, André Pönitz wrote:
> 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:
I'm Sorry for the inconvience.

> 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.'
Aha, Seems gdb works better in Linux system than Windows.

> 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.
fully agree, Hopefully the GDB gurus can fix it.

Asmwarrior

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

[Tom Tromey]

>>>>> "André" == André Pönitz <andre.poenitz@nokia.com> writes:

André> However, I do not use the gdb version of the pretty printers for
André> the stability reason you just encountered, and because they
André> cannot (easily...) create several layers including possibly
André> "virtual" ones that do not correspond to actual objects on the
André> inferior side.

I don't understand this latter comment, but I would like to.
Could you give an example?  Or explain it in more depth?

Tom

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

[André Pönitz]

On Saturday 16 October 2010 00:38:23 you wrote:
> >>>>> "André" == André Pönitz <andre.poenitz@nokia.com> writes:
> 
> André> However, I do not use the gdb version of the pretty printers for
> André> the stability reason you just encountered, and because they
> André> cannot (easily...) create several layers including possibly
> André> "virtual" ones that do not correspond to actual objects on the
> André> inferior side.
> 
> I don't understand this latter comment, but I would like to.
> Could you give an example?  Or explain it in more depth?

The MI varobject based infrastructure creates one level of information
at a time. So it is not easy to create displays of "virtual levels" or
items that do not actually "live" in the inferior. Displays like

  Name                       Value            Type

  someObject                  0x2312413        SomeType
      properties 
           property1            "MyName"          String      (stored in a member of the object)
           property2            Nov 11, 2010     Date       (perhaps in current locale)
           property3            "Some Street"    String      (perhaps coming from a database)
      children
           ...
      parents
           ...
      connections
           ...

are very hard to create in this world, yet such display can be _very_ 
convenient when debugging applications above the "bare metal" level.

I actually claim that certain displays are impossible to handle with the MI
varobject approach -- even under the assumption that it would work well
otherwise (i.e. handle anonymous structs, hidden variables in outer scope,
gracefully cope with uninitialized/corrupted data, need not several
roundtrips to setup, had a way to reduce repeated data etc)

I seriously believe that with full python scripting being available in gdb
there is no need to use MI varobjects at all. 

Unfortunately, gdb's own python based pretty printing does not use
this new freedom but is modeled very similar to the varobject setup 
and therefore shares (needlessly if I may add) some of the varobject 
shortcomings.

Andre'

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

[Tom Tromey]

>>>>> ">" == 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

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

[asmwarrior]

  On 2010-10-16 6:36, Tom Tromey wrote:
> Interesting.  Maybe a bug in valpy_lazy_string.
> Could you file this as a bug report?
Done, see:

http://sourceware.org/bugzilla/show_bug.cgi?id=12127

thanks.

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

[asmwarrior]

On 2010-10-20 4:17, Tom Tromey wrote:
 > reading variable s (Cannot access memory at address 0x80)
 > Tom> I am working on a fix for this.
 >
 > Tom> Currently all gdb exceptions are convert to a Python 
RuntimeError.  But,
 > Tom> I think we should differentiate a little more.  In particular, I 
think a
 > Tom> gdb MEMORY_ERROR should be a separate class, and should be handled
 > Tom> specially by the pretty-printing code (basically by omitting the 
stack
 > Tom> trace).
 >
 > This patch implements this idea.  It adds some new subclasses of
 > RuntimeError, including one specifically for MEMORY_ERROR.  Then it
 > arranges for the memory error exception to be treated specially by the
 > pretty-printing code.
 >
 > Built and regtested on x86-64 (compile farm).
 > Some new test cases are included.
 >
 > asmwarrior, it would be helpful if you could try this out.
 >
 > Ok?
 >
 > Tom
 >
OK.


I just use git to check out the latest whole gdb source (>100M)
Then apply your patch

Then use MSYS + MINGW GCC 4.4.4 to build it .

But I failed with the build error. like:

../../gdb/libiberty/fibheap.c:151: warning: incompatible implicit 
declaration of
  built-in function 'free'
../../gdb/libiberty/fibheap.c:156: warning: incompatible implicit 
declaration of
  built-in function 'free'
../../gdb/libiberty/fibheap.c:172: warning: incompatible implicit 
declaration of
  built-in function 'free'
../../gdb/libiberty/fibheap.c: In function 'fibheap_extract_min':
../../gdb/libiberty/fibheap.c:190: warning: incompatible implicit 
declaration of
  built-in function 'free'
../../gdb/libiberty/fibheap.c: In function 'fibheap_replace_key_data':
../../gdb/libiberty/fibheap.c:220: error: 'LONG_MIN' undeclared (first 
use in th
is function)
../../gdb/libiberty/fibheap.c:220: error: (Each undeclared identifier is 
reporte
d only once
../../gdb/libiberty/fibheap.c:220: error: for each function it appears in.)
../../gdb/libiberty/fibheap.c: In function 'fibheap_delete_node':
../../gdb/libiberty/fibheap.c:261: error: 'LONG_MIN' undeclared (first 
use in th
is function)
../../gdb/libiberty/fibheap.c:265: warning: implicit declaration of 
function 'ab
ort'
../../gdb/libiberty/fibheap.c:265: warning: incompatible implicit 
declaration of
  built-in function 'abort'
../../gdb/libiberty/fibheap.c: In function 'fibheap_delete':
../../gdb/libiberty/fibheap.c:277: warning: incompatible implicit 
declaration of
  built-in function 'free'
../../gdb/libiberty/fibheap.c: In function 'fibheap_consolidate':
../../gdb/libiberty/fibheap.c:368: warning: implicit declaration of 
function 'me
mset'
../../gdb/libiberty/fibheap.c:368: warning: incompatible implicit 
declaration of
  built-in function 'memset'
make[2]: *** [fibheap.o] Error 1
make[2]: Leaving directory `e:/test/build/libiberty'
make[1]: *** [all-libiberty] Error 2
make[1]: Leaving directory `e:/test/build'
make: *** [all] Error 2

When I manually add this macro definition then continue the build, I got 
other more errors.

I can remember that the snapshot of GDB source 20101005, I can build it 
successful. I'm not sure why.

Asmwarrior.

BTW:

My friend Loaden has some build errors when building gdb.exe (weekly 
20101019) from linux, here is his build log:

  /bin/install -c -m 644 ../../../../src/gdb/bfd/doc/bfd.info 
'/home/loaden/gdb/share/info'
  install-info --info-dir='/home/loaden/gdb/share/info' 
'/home/loaden/gdb/share/info/bfd.info'
make[4]: Leaving directory `/home/loaden/AUR/gdb/build/gdb-win/bfd/doc'
Making install in po
make[4]: Entering directory `/home/loaden/AUR/gdb/build/gdb-win/bfd/po'
if test -r ../../../../src/gdb/bfd/../mkinstalldirs; then \
       ../../../../src/gdb/bfd/../mkinstalldirs /home/loaden/gdb/share; \
     else \
       ../../../../src/gdb/bfd/mkinstalldirs /home/loaden/gdb/share; \
     fi
/bin/sh: line 1: ../../../../src/gdb/bfd/../mkinstalldirs: Permission denied
make[4]: *** [install-data-yes] Error 126
make[4]: Leaving directory `/home/loaden/AUR/gdb/build/gdb-win/bfd/po'
make[4]: Entering directory `/home/loaden/AUR/gdb/build/gdb-win/bfd'
make[5]: Entering directory `/home/loaden/AUR/gdb/build/gdb-win/bfd'
make[5]: Nothing to be done for `install-exec-am'.
test -z "/home/loaden/gdb/include" || /bin/mkdir -p 
"/home/loaden/gdb/include"
  /bin/install -c -m 644 bfd.h 
../../../src/gdb/bfd/../include/ansidecl.h 
../../../src/gdb/bfd/../include/symcat.h 
../../../src/gdb/bfd/../include/bfdlink.h '/home/loaden/gdb/include'
test -z "/home/loaden/gdb/lib" || /bin/mkdir -p "/home/loaden/gdb/lib"
  /bin/sh ./libtool   --mode=install /bin/install -c   libbfd.la 
'/home/loaden/gdb/lib'
libtool: install: /bin/install -c .libs/libbfd.lai 
/home/loaden/gdb/lib/libbfd.la
libtool: install: /bin/install -c .libs/libbfd.a 
/home/loaden/gdb/lib/libbfd.a
libtool: install: chmod 644 /home/loaden/gdb/lib/libbfd.a
libtool: install: i686-mingw32-ranlib /home/loaden/gdb/lib/libbfd.a
libtool: install: warning: remember to run `libtool --finish 
/home/loaden/AUR/gdb/depends/lib'
make[5]: Leaving directory `/home/loaden/AUR/gdb/build/gdb-win/bfd'
make[4]: Leaving directory `/home/loaden/AUR/gdb/build/gdb-win/bfd'
make[3]: *** [install-recursive] Error 1
make[3]: Leaving directory `/home/loaden/AUR/gdb/build/gdb-win/bfd'
make[2]: *** [install] Error 2
make[2]: Leaving directory `/home/loaden/AUR/gdb/build/gdb-win/bfd'
make[1]: *** [install-bfd] Error 2
make[1]: Leaving directory `/home/loaden/AUR/gdb/build/gdb-win'
make: *** [install] Error 2

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

[asmwarrior]

My test report:

Thought my friend Loaden has some build error when he try to cross build 
the gdb.exe from linux, but finally he the gdb.exe has generated. ( the 
error my due some other module)

(latest weekly 20202018 and with the patch: 
http://sourceware.org/ml/gdb-patches/2010-10/msg00301.html)

I just test it with the same sample code:

#include <wx/wx.h>
#include <string>
#include <map>
#include <list>
#include <stack>
#include <vector>

int main()
{
wxString wxStr(L"wxString");
wxStr += L" Value";
std::string stdStr("std::string");
stdStr.append(" value");
std::map<int, std::string> m;
m[0] = "000";
m[1] = "111";
wxString& wxStrRef = wxStr;
wxStrRef += L" Ref";
std::string& stdStrRef = stdStr;
stdStrRef += " Ref";

std::list<std::string> l = {"a", "b", "c"};
std::vector<std::string> v = {"a", "b", "c"};

std::stack<std::string> s;
s.push("a");
s.push("b");

return 0;
}


Set a breakpoint in the first line of main(), then the result gives below:

Breakpoint 2, main () at F:\cb\test_code\gdbpython-demo\main.cpp:10
F:\cb\test_code\gdbpython-demo\main.cpp:10:126:beg:0x4013d3
 >>>>>>cb_gdb:
 > set debugevents off
 >>>>>>cb_gdb:
 > bt 30
#0 main () at F:\cb\test_code\gdbpython-demo\main.cpp:10
 >>>>>>cb_gdb:
 > p l
Cannot access memory at address 0x50000069
$1 = std::list = {
[0] = >>>>>>cb_gdb:
 > p s
Cannot access memory at address 0x80
$2 = std::stack wrapping: std::deque with -521324573 elements = 
{>>>>>>cb_gdb:
 > p m
$3 = 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']:
gdb.error: Attempt to dereference a generic pointer.
 >>>>>>cb_gdb:
 > p wxStr
$4 = UnicodeEncodeError: 'gbk' codec can't encode character u'\uffff' in 
position 0: illegal multibyte sequence
 >>>>>>cb_gdb:
 > p stdStr
$5 = 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
 >>>>>>cb_gdb:


it seems the only failing case is I try to print the vector

p v

$1 = std::vector of length -37952, capacity -519864265 = {<error reading
variable: Cannot access memory at address 0x90000cb6>,<error reading
variable: Cannot access memory at address 0x90909084>,<error reading
variable: Cannot access memory at address 0xe77d74>,<error reading
variable: Cannot access memory at address 0x458b0e68>,<error reading
variable: Cannot access memory at address 0x78b0ffcc>,<error reading
variable: Cannot access memory at address 0xe7fffff9>,<error reading
variable: Cannot access memory at address 0xfff91191>,<error reading
variable: Cannot access memory at address 0x909090b7>,<error reading
variable: Cannot access memory at address 0xffffff84>,<error reading
variable: Cannot access memory at address 0xf3>,<error reading
variable: Cannot access memory at address 0x96ff2ef4>,<error reading
variable: Cannot access memory at address 0x70>,<error reading
variable: Cannot access memory at address 0x96fed2f4>,<error reading
variable: Cannot access memory at address 0x96fee670>,<error reading
variable: Cannot access memory at address 0x6c745270>,<error reading
variable: Cannot access memory at address 0x657a6947>,<error reading
variable: Cannot access memory at address 0x7061653c>,<error reading
variable: Cannot access memory at address 0x6c7451f4>,<error reading
variable: Cannot access memory at address 0x657a6947>,<error reading
variable: Cannot access memory at address 0x7061653c>,<error reading
variable: Cannot access memory at address 0xcccccbf4>,<error reading
variable: Cannot access memory at address 0x90ccccc0>,<error reading
variable: Cannot access memory at address 0x90909084>,<error reading
variable: Cannot access memory at address 0x8868205e>,<error reading
variable: Cannot access memory at address 0xe87c96f4>,<error reading
variable: Cannot access memory at address 0xfff9e930>,<error reading
variable: Cannot access memory at address 0x8908757f>,<error reading
variable: Cannot access memory at address 0x45c6d869>,<error reading
variable: Cannot access memory at address 0x46f600db>,<error reading
variable: Cannot access memory at address 0xe740107>,<error reading
variable: Cannot access memory at address 0x560c75f3>,<error reading
variable: Cannot access memory at address 0xffaf99dc>,<error reading
variable: Cannot access memory at address 0xb6e9f3>,<error reading
variable: Cannot access memory at address 0xff32fff4>,<error reading
variable: Cannot access memory at address 0x89e07d7d>,<error reading
variable: Cannot access memory at address 0xdb33fc71>,<error reading
variable: Cannot access memory at address 0xfc5d8937>,<error reading
variable: Cannot access memory at address 0x9700a05c>,<error reading
variable: Cannot access memory at address 0x37e85670>,<error reading
variable: Cannot access memory at address 0x84fffa26>,<error reading
variable: Cannot access memory at address 0x890575b4>,<error reading
variable: Cannot access memory at address 0x3bebe071>,<error reading
variable: Cannot access memory at address 0xd10467f>,<error reading
variable: Cannot access memory at address 0xffffff4>,<error reading
variable: Cannot access memory at address 0x840c44fd>,<error reading
variable: Cannot access memory at address 0x11750c51>,<error reading
variable: Cannot access memory at address 0x578b6f3>,<error reading
variable: Cannot access memory at address 0x16e7fff4>,<error reading
variable: Cannot access memory at address 0x88fff904>,
"\000u\000r\000r\000e\000n\000t\000V\000e\000r\000s\000i\000o\000n\000
\\\000F\000o\000n\000t\000S\000u\000b\000s\000t\000i\000t\000u\000t
\000e\000s\000\000\000悙媅SO\000\000悙癳0}\016f詺\000\000SV\350\n\000
\000 \000\351\f\210\377\377悙悙悑\377U嬱\203%\\>\020]\000V媢\b咑tU\213
.....

[a lot of raw memory dump and gdb crashed.]


Compare with my original post
http://sourceware.org/ml/gdb/2010-10/msg00045.html
the only different is that when I print the vector in an old gdb (20101005 with out your patch), the result is :

both stdStr, wxStr, m, works fine.

but print vector let gdb crashed either.

>  p v
$5 = 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):
   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 0xe77d74
, 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 0x458b0e68
, 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 0x78b0ffcc
, 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 0xe7fffff9




As a conclusion, this issue is still exist and not fixed.

asmwarrior

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

[Tom Tromey]

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

asmwarrior> I just use git to check out the latest whole gdb source (>100M)
asmwarrior> Then apply your patch

asmwarrior> Then use MSYS + MINGW GCC 4.4.4 to build it .

asmwarrior> But I failed with the build error. like:

That seems weird, like maybe you are missing a header file.
I don't know for certain what it is, though; you'll have to debug it.

asmwarrior> /bin/sh: line 1: ../../../../src/gdb/bfd/../mkinstalldirs: Permission denied

This file should be +x.

Tom

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

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: "gdb\@sourceware.org" <gdb@sourceware.org>, gdb-patches@sourceware.org
> Date: Fri, 22 Oct 2010 13:17:04 -0600
> 
> asmwarrior> /bin/sh: line 1: ../../../../src/gdb/bfd/../mkinstalldirs: Permission denied
> 
> This file should be +x.

There's no such thing on Windows.

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

[Joel Brobecker]

> > asmwarrior> /bin/sh: line 1: ../../../../src/gdb/bfd/../mkinstalldirs: Permission denied
> > 
> > This file should be +x.
> 
> There's no such thing on Windows.

Yes, because it's a script, the makefile should execute it via $SHELL.
I see that we're making the same error in gdb/doc, for instance, so
it looks like we would be unable to build the documentation if building
using MinGW tools.

I am flying back this evening, so I will try to remember to send a patch
soon.

-- 
Joel

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

[Eli Zaretskii]

> Date: Fri, 29 Oct 2010 15:18:20 -0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Tom Tromey <tromey@redhat.com>, asmwarrior@gmail.com,	gdb@sourceware.org, gdb-patches@sourceware.org
> 
> Yes, because it's a script, the makefile should execute it via $SHELL.
> I see that we're making the same error in gdb/doc, for instance, so
> it looks like we would be unable to build the documentation if building
> using MinGW tools.

If you are using the MinGW port of GNU Make, it will always use sh.exe
(if it can find it on your PATH) automatically to run any shell
scripts invoked by the Makefile.  I just tried that with a MinGW build
of Make 3.82, and commands like "./mkinstalldirs foo/bar" just work (I
do have a sh.exe).  This works because the function process_begin on
w32/subproc/sub_proc.c has code to detect a Unix shell script and
DTRT.

So there's some other factor at work here.  Or maybe the sh.exe which
is installed on the OP's machine has some issues that mine doesn't.

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

[asmwarrior]

On 3:59, Eli Zaretskii wrote:
>> Date: Fri, 29 Oct 2010 15:18:20 -0400
>> From: Joel Brobecker<brobecker@adacore.com>
>> Cc: Tom Tromey<tromey@redhat.com>, asmwarrior@gmail.com,	gdb@sourceware.org, gdb-patches@sourceware.org
>>
>> Yes, because it's a script, the makefile should execute it via $SHELL.
>> I see that we're making the same error in gdb/doc, for instance, so
>> it looks like we would be unable to build the documentation if building
>> using MinGW tools.
>
> If you are using the MinGW port of GNU Make, it will always use sh.exe
> (if it can find it on your PATH) automatically to run any shell
> scripts invoked by the Makefile.  I just tried that with a MinGW build
> of Make 3.82, and commands like "./mkinstalldirs foo/bar" just work (I
> do have a sh.exe).  This works because the function process_begin on
> w32/subproc/sub_proc.c has code to detect a Unix shell script and
> DTRT.
>
> So there's some other factor at work here.  Or maybe the sh.exe which
> is installed on the OP's machine has some issues that mine doesn't.
Hi Eli
I use the configure make command directly in the MSYS shell. So I think 
they by default use the GNU make (not the mingw32-make).

But I run the make -v on the MSYS shell, it gives the version number 
3.81. So I will try 3.82 as your mentioned.

Asmwarrior

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

[asmwarrior]

On 2010-10-23 5:21, Eli Zaretskii wrote:
>> From: Tom Tromey<tromey@redhat.com>
>> Cc: "gdb\@sourceware.org"<gdb@sourceware.org>, gdb-patches@sourceware.org
>> Date: Fri, 22 Oct 2010 13:17:04 -0600
>>
>> asmwarrior>  /bin/sh: line 1: ../../../../src/gdb/bfd/../mkinstalldirs: Permission denied
>>
>> This file should be +x.
> There's no such thing on Windows.
Dear GDB gurus, Today, I just do a git pull, then try to build the gdb 
again. but I still failed under building gdb under windows/msys.

Here is the configure:
cd build
../gdb/configure --host=mingw32 --target=mingw32 \
    --prefix=/E/test/install \
    --build=mingw32 CFLAGS="-s -L/python/libs -I/python/include 
-I/E/test/expat/install/include -static -L/E/test/expat/install/lib" \
    --with-python \
    --with-expat

and here is the build error when running the make command.

mingw32-gcc -c -DHAVE_CONFIG_H -s -L/python/libs -I/python/include 
-I/E/test/exp
at/install/include -static -L/E/test/expat/install/lib 
-D__USE_MINGW_ACCESS  -I.
  -I../../gdb/libiberty/../include  -W -Wall -Wwrite-strings 
-Wc++-compat -Wstric
t-prototypes -pedantic  ../../gdb/libiberty/fibheap.c -o fibheap.o
../../gdb/libiberty/fibheap.c: In function 'fibheap_union':
../../gdb/libiberty/fibheap.c:151: warning: implicit declaration of 
function 'fr
ee'
../../gdb/libiberty/fibheap.c:151: warning: incompatible implicit 
declaration of
  built-in function 'free'
../../gdb/libiberty/fibheap.c:156: warning: incompatible implicit 
declaration of
  built-in function 'free'
../../gdb/libiberty/fibheap.c:172: warning: incompatible implicit 
declaration of
  built-in function 'free'
../../gdb/libiberty/fibheap.c: In function 'fibheap_extract_min':
../../gdb/libiberty/fibheap.c:190: warning: incompatible implicit 
declaration of
  built-in function 'free'
../../gdb/libiberty/fibheap.c: In function 'fibheap_replace_key_data':
../../gdb/libiberty/fibheap.c:220: error: 'LONG_MIN' undeclared (first 
use in th
is function)
../../gdb/libiberty/fibheap.c:220: error: (Each undeclared identifier is 
reporte
d only once
../../gdb/libiberty/fibheap.c:220: error: for each function it appears in.)
../../gdb/libiberty/fibheap.c: In function 'fibheap_delete_node':
../../gdb/libiberty/fibheap.c:261: error: 'LONG_MIN' undeclared (first 
use in th
is function)
../../gdb/libiberty/fibheap.c:265: warning: implicit declaration of 
function 'ab
ort'
../../gdb/libiberty/fibheap.c:265: warning: incompatible implicit 
declaration of
  built-in function 'abort'
../../gdb/libiberty/fibheap.c: In function 'fibheap_delete':
../../gdb/libiberty/fibheap.c:277: warning: incompatible implicit 
declaration of
  built-in function 'free'
../../gdb/libiberty/fibheap.c: In function 'fibheap_consolidate':
../../gdb/libiberty/fibheap.c:368: warning: implicit declaration of 
function 'me
mset'
../../gdb/libiberty/fibheap.c:368: warning: incompatible implicit 
declaration of
  built-in function 'memset'
make[2]: *** [fibheap.o] Error 1
make[2]: Leaving directory `/e/test/build/libiberty'
make[1]: *** [all-libiberty] Error 2
make[1]: Leaving directory `/e/test/build'
make: *** [all] Error 2


thank you very much.

asmwarrior

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

[Tom Tromey]

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

>> Dear GDB gurus, Today, I just do a git pull, then try to build the gdb
>> again. but I still failed under building gdb under windows/msys.

>> ../../gdb/libiberty/fibheap.c: In function 'fibheap_union':
>> ../../gdb/libiberty/fibheap.c:151: warning: implicit declaration of
>> function 'free'

It sounds like HAVE_STDLIB_H is not defined.
libiberty's config.log might show why.

Tom

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

[Tom Tromey]

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

>> the attachment is the config.log file under libiberty
>> I know little about automake system.
>> Hope it will help to find the bug.

Apparently HAVE_STDLIB_H is defined after all.
So, I'm afraid I don't know what is going on.

Tom

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

[asmwarrior]

On 2010-11-16 2:10, Tom Tromey wrote:
>> Apparently HAVE_STDLIB_H is defined after all.
>> So, I'm afraid I don't know what is going on.
>>
>> Tom


Hi, Tom, After struggling with the building gdb, I finally found a very 
strange build problem.

under MSYS and MinGW 4.4.5.

Today, I can build the gdb source from the snapshot: 
gdb-7.2.50.20101213.tar.bz2
I have already released in the codeblocks' forum post:

http://forums.codeblocks.org/index.php/topic,11301.0.html


But the real strange thing is: I failed build the gdb from the git 
working copy.
The error is just like the same as I reported several days ago. that is:
--------------------------------------------------------------------------------
of built-in function 'free'
../../gdb/libiberty/fibheap.c: In function 'fibheap_extract_min':
../../gdb/libiberty/fibheap.c:
190:7: warning: incompatible implicit declaration

of built-in function 'free'
../../gdb/libiberty/fibheap.c: In function 'fibheap_replace_key_data':
../../gdb/libiberty/fibheap.c:220:30: error: 'LONG_MIN' undeclared 
(first use in
  this function)
../../gdb/libiberty/fibheap.c:220:30: note: each undeclared identifier 
is report
ed only once for each function it appears in
../../gdb/libiberty/fibheap.c: In function 'fibheap_delete_node':
../../gdb/libiberty/fibheap.c:261:36: error: 'LONG_MIN' undeclared 
(first use in
  this function)
../../gdb/libiberty/fibheap.c:265:7: warning: implicit declaration of 
function '
abort'
../../gdb/libiberty/fibheap.c:265:7: warning: incompatible implicit 
declaration

of built-in function 'abort'
../../gdb/libiberty/fibheap.c: In function 'fibheap_delete':
../../gdb/libiberty/fibheap.c:277:5: warning: incompatible implicit 
declaration

of built-in function 'free'
../../gdb/libiberty/fibheap.c: In function 'fibheap_consolidate':
../../gdb/libiberty/fibheap.c:368:3: warning: implicit declaration of 
function '
memset'
../../gdb/libiberty/fibheap.c:368:3: warning: incompatible implicit 
declaration
of built-in function 'memset'
make[2]: *** [fibheap.o] Error 1

make[2]: Leaving directory `/e/test/build/libiberty'
make[1]: *** [all-libiberty] Error 2
make[1]: Leaving directory `/e/test/build'
make: *** [all] Error 2
--------------------------------------------------------------------------------

I have both a folder named "gdb" (this is the git working copy)
and a folder named "gdb-7.2.50.20101213" (this is unzipped snapshot)

Then this command works:

cd build
../gdb-7.2.50.20101213/configure --prefix=/E/test/install 
--build=mingw32 --host=mingw32 --target=mingw32 \
    CFLAGS="-s -L/python/libs -I/python/include 
-I/E/test/expat/install/include -static -L/E/test/expat/install/lib" \
    --with-python \
    --with-expat
make
---------------------------------------------------------------------------------

But this command failed with the error I shown above:

cd build
../gdb/configure --prefix=/E/test/install --build=mingw32 --host=mingw32 
--target=mingw32 \
    CFLAGS="-s -L/python/libs -I/python/include 
-I/E/test/expat/install/include -static -L/E/test/expat/install/lib" \
    --with-python \
    --with-expat
make

----------------------------------------------------------------------------------

by the way, the gdb git address I'm using is:

git clone git://sourceware.org/git/gdb.git

list here:

http://www.gnu.org/software/gdb/current/

Any ideas?

thanks.

asmwarrior

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

[Tom Tromey]

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

>> Today, I can build the gdb source from the snapshot:
>> gdb-7.2.50.20101213.tar.bz2

>> But the real strange thing is: I failed build the gdb from the git
>> working copy.

>> by the way, the gdb git address I'm using is:
>> git clone git://sourceware.org/git/gdb.git

>> list here:
>> http://www.gnu.org/software/gdb/current/

>> Any ideas?

I don't know of any problem offhand.  I do builds from the git mirror
regularly without problems, but of course I'm on a different host.

All I can suggest is to debug it.

If I had this problem I might start by comparing the snapshot and git
source trees.  Though, TBH, I'd be surprised to find anything weird
there.

Next I would try to understand why exactly the build failed in
libiberty, and track down the problem.

Tom

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

[asmwarrior]

On 2010-12-14 23:00, Tom Tromey wrote:
> I don't know of any problem offhand.  I do builds from the git mirror
> regularly without problems, but of course I'm on a different host.
>
> All I can suggest is to debug it.
>
> If I had this problem I might start by comparing the snapshot and git
> source trees.  Though, TBH, I'd be surprised to find anything weird
> there.
>
> Next I would try to understand why exactly the build failed in
> libiberty, and track down the problem.
>
> Tom
Hi, Tom, Here are the good news.

  With the great help of Codeblocks' forum user "xunxun1982"
(http://forums.codeblocks.org/index.php?action=profile;u=12871), and 
several days testing and struggling. Now, the problem was totally solved.

In-fact, the problem is that the MSYS configure program can NOT 
correctly handling the Windows CR LF newline. When I use the MSYS Git to 
check out the git gdb working copy, all the source in the gdb working 
copy was encoded by CRLF format. and this cause many weird building 
errors. (since the snapshot of gdb source use LF format, so I can 
successfully build them).

Here are the steps to solve the problem:

1, open the file:
E:\PortableGit-1.7.3.1-preview20101002(1)\etc\gitconfig
and change the line
autocrlf = true
to
autocrlf = false

this can stop the git to change the style from LF to CRLF.

2, get the gdb git copy again (now, all the source was in UNIX LF style)

3, configure and make to build the gdb.


Now, everything works fine!!! I have successfully build the gdb from the 
git source under MSYS and MinGW 4.5.2. Wonderful!!!

asmwarrior

Re: RFA: add python exception subclasses

[Tom Tromey]

>>>>> ">" == asm warrior <asmwarrior@gmail.com> writes:

>> It seems this patch was already in the cvs trunk, but using the latest gdb I
>> build myself yesterday(MSYS+MinGW). gdb still crashes when showing
>> uninitialized vector<string>.

Could you post the session and a backtrace?

Tom

Re: RFA: add python exception subclasses

[asmwarrior]

On 2010-12-18 3:04, Tom Tromey wrote:
>>> It seems this patch was already in the cvs trunk, but using the latest gdb I
>>> build myself yesterday(MSYS+MinGW). gdb still crashes when showing
>>> uninitialized vector<string>.
> Could you post the session and a backtrace?
>
> Tom
since the previous reply was reject by the mail-list, I create a compact 
one.

log here(some text removed)
--------------------------------------------------------------------

 > p v
$1 = std::vector of length -259079, capacity -521893089 = {<error 
reading variable: Cannot access memory at address 0x900014b6>, <error 
reading variable: Cannot access memory at address 0x34ac>, <error 
reading variable: Cannot access memory at address 0x300b9f4>, <error 
reading variable: Cannot access memory at address 0x12ff7ff2>, <error 
reading variable: Cannot access memory at address 0x900010b6>, <error 
reading variable: Cannot access memory at address 0x35ac>, <error 
reading variable: Cannot access memory at address 0x300b9f4>, <error 
reading variable: Cannot access memory at address 0x12ff7ff2>, <error 
reading variable:

.....

<error reading variable: Cannot access memory at address 0x12ff7ff2>, 
"s\000\037\066\003\326\025\000\000\001\020%\000\000\025_\037\000\000\025\020%\000\000\025\326\025\000\000\025\213$\000\000\000\063\004\221\036\000\000E\001putwc\000\037%\002\320\037\000\000\001\065%\000\000\025\244\026\000\000\025j#\000\000\000E\001putwchar\000\037\221\002\320\037\000\000\001R%\000\000\025\244\026\000\000\000E\001swscanf\000\037r\002\221\025\000\000\001t%\000\000\025e\037\000\000\025e\037\000\000F\000E\001ungetwc\000\037'\002\320\037\000\000\001\225%\000\000\025\320\037\000\000\025j#\000\000\000E\001vfwprintf\000\037/\002\221\025\000\000\001\275%\000\000\025j#\000\000\025e\037\000\000\025\236\037\000\000\000E\001vfwscanf\000\037B\002\221\025\000\000\001\344%\000\000\025j#\000\000\025e\037\000\000\025\236\037\000\000\000E\001vswscanf\000\037C\002\221\025\000\000\001\v&\000\000\025e\037\000\000\025e\037\000\000\025\236\037\000\000\000E\001vwprintf\000\037\060\002\221\025\000\000\001-&\000\000\025e\037\000\000\025\236\037\000\000\000E\001vwscanf\000\037A
....

<error reading variable: Cannot access memory at address 0xdd08ec77>, 
<error reading variable: Cannot access memory at address 0x448b2408>, 
<error reading variable: Cannot access memory at address 0xc4830418>, 
<error reading variable: Cannot access memory at address 0x24fc>, <error 
reading variable: Cannot access memory at address 0x3d747fe4>, <error 
reading variable: Cannot access memory at address 0xf0000031>, <error 
reading variable: Cannot access memory at address 0x665f7473>, <error 
reading variable: Cannot access memory at address 0x6624047f>, <error 
reading variable: Cannot access memory at address 0x74027f31>, <error 
reading variable: Cannot access memory at address 0xe083661e>, <error 
reading variable: Cannot access memory at address 0x9b217514>, <error 
reading variable: Cannot access memory at address 0x8366e0d3>, <error 
reading variable: Cannot access memory at address 0x187420d4>, <error 
reading variable: Cannot access memory at address 0x8ac>, <error reading 
variable: Cannot access memory at address 0x1dfa82f4>, <error reading 
variable: Cannot access memory at address 0xb2e80768>, <error reading 
variable: Cannot access memory at address 0x59fffff4>, <error reading 
variable: Cannot access memory at address 0x94e8b7>, <error reading 
variable: Cannot access memory at address 0xc359fff4>, <error reading 
variable: Cannot access memory at address 0x5a242ccd>, <error reading 
variable: Cannot access memory at address 0xe005ddb7>, <error reading 
variable: Cannot access memory at address 0xd97c90d7>, <error reading 
variable: Cannot access memory at address 0xddfdd9bd>, <error reading 
variable: Cannot access memory at address 0xd9c0d9cd>, <error reading 
variable: Cannot acces
This application has requested the Runtime to terminate it in an unusual 
way.
Please contact the application's support team for more information.



--------------------------------------------------------------------
the test code was quite simple:

#include <wx/wx.h>
#include <string>
#include <map>
#include <list>
#include <stack>
#include <vector>

int main()
{
      wxString wxStr(L"wxString");
      wxStr += L" Value";
      std::string stdStr("std::string");
      stdStr.append(" value");
      std::map<int, std::string> m;
      m[0] = "000";
      m[1] = "111";
      wxString& wxStrRef = wxStr;
      wxStrRef += L" Ref";
      std::string& stdStrRef = stdStr;
      stdStrRef += " Ref";

      std::list<std::string> l = {"a", "b", "c"};
      std::vector<std::string> v = {"a", "b", "c"};

      std::stack<std::string> s;
      s.push("a");
      s.push("b");

      return 0;
}

and set break-point in the first line. then run the "p v" command.
Hope this helps. thanks.

asmwarrior