gdb crash when I try to print a std::queue (Windows)

gdb crash when I try to print a std::queue (Windows)

[asmwarrior]

Hi,I'm bulding a cvs head gdb with python enabled. I'm using Windows XP.
When I try to print a std::queue, gdb crashed. I use a another gdb to test the crash bug.

My test code is below:

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

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

#include <windows.h>


const static std::string apms[5]={"&amp;","&lt;","&gt;","&quot;","&apos;"};


int main()
{
    wxString *psty = (wxString*) NULL;
    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::queue<std::string> q;
    q.push("a");
    q.push("b");

    std::stack<std::string> s;
    s.push("a");
    s.push("b");
    asm("int $3");

    return 0;
}
-------------------------------------------------
You can remove all the other stuffs and leave only the std::queue code.

I build it in mingw gcc 4.4.5, here is the debug log: 
gdb-python27.exe is the "debugger", and gdb.exe is the "debugee".
the command "source stl.gdb" is just loading the std c++'s python pretty printer. 

E:\code\test_gdb>gdb-python27.exe gdb.exe
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 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 "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from e:\code\test_gdb\gdb.exe...done.
(gdb) r
Starting program: e:\code\test_gdb\gdb.exe
[New Thread 3644.0x1148]
GNU gdb (GDB) 7.3.50.20111030-cvs
Copyright (C) 2011 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 "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) [New Thread 3644.0x194]
[New Thread 3644.0x1370]
file a1.exe
Reading symbols from e:\code\test_gdb\a1.exe...done.
(gdb) source stl.gdb
(gdb) r
Starting program: e:\code\test_gdb\a1.exe
[New Thread 4964.0x1700]

Program received signal SIGTRAP, Trace/breakpoint trap.
main () at e:\code\cb\test_code\gdbpython-demo\main.cpp:41
41          return 0;
(gdb) python print 3
3
(gdb) p q
$1 =
Program received signal SIGSEGV, Segmentation fault.
0x77c47a64 in strncmp () from C:\WINDOWS\system32\msvcrt.dll
(gdb) bt
#0  0x77c47a64 in strncmp () from C:\WINDOWS\system32\msvcrt.dll
#1  0x005a6474 in typy_lookup_typename (type_name=0x0, block=0x0)
    at ../../gdb/gdb/python/py-type.c:586
#2  0x005a66f3 in typy_lookup_type (demangled=0x5015a90, block=0x0)
    at ../../gdb/gdb/python/py-type.c:650
#3  0x005a6867 in typy_legacy_template_argument (type=0x508f3a0, block=0x0,
    argno=0) at ../../gdb/gdb/python/py-type.c:714
#4  0x005a6a09 in typy_template_argument (self=0x2d147b8, args=0x2d2c7d0)
    at ../../gdb/gdb/python/py-type.c:759
#5  0x1e08883b in python27!PyCFunction_Call ()
   from E:\code\common_bin\python27.dll
#6  0x1e0bf781 in python27!PyEval_GetFuncDesc ()
   from E:\code\common_bin\python27.dll
#7  0x02d50080 in ?? ()
#8  0x1e1d57f8 in python27!PySuper_Type ()
   from E:\code\common_bin\python27.dll
#9  0x00000001 in ?? ()
#10 0x02a4e684 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) frame 1
#1  0x005a6474 in typy_lookup_typename (type_name=0x0, block=0x0)
    at ../../gdb/gdb/python/py-type.c:586
586           if (!strncmp (type_name, "struct ", 7))
(gdb) info locals
type = 0x0
except = {reason = 0, error = GDB_NO_ERROR, message = 0x0}
(gdb) info args
type_name = 0x0
block = 0x0
(gdb)


So, it looks like the crash is here:

\gdb\python\py-type.c

static struct type *
typy_lookup_typename (const char *type_name, const struct block *block)
{
  struct type *type = NULL;
  volatile struct gdb_exception except;

  TRY_CATCH (except, RETURN_MASK_ALL)
    {
      if (!strncmp (type_name, "struct ", 7))
    type = lookup_struct (type_name + 7, NULL);
      else if (!strncmp (type_name, "union ", 6))
    type = lookup_union (type_name + 6, NULL);
      else if (!strncmp (type_name, "enum ", 5))
    type = lookup_enum (type_name + 5, NULL);
      else
    type = lookup_typename (python_language, python_gdbarch,
                type_name, block, 0);
    }
  if (except.reason < 0)
    {
      gdbpy_convert_exception (except);
      return NULL;
    }

  return type;
}

It looks like the input argument "type_name" and "block" is all ZERO.

Any ideas?
Is it possible just add a condition check like:

if(type_name==0)
   return NULL;


--------------------------------------------------------------------
BTW: if I build my test code under mingw gcc 4.6.2, then there's no crash here, and "p q" can correctly show the std::queue's contents from pretty printer.

BTW2: my friend xunxun can test the code under Win7, and it seems  there's no crash.

asmwarrior
ollydbg from codeblocks' forum

Re: gdb crash when I try to print a std::queue (Windows)

[asmwarrior]

On 2011-10-30 21:23, asmwarrior wrote:
> Is it possible just add a condition check like:
> 
> if(type_name==0)
>     return NULL;
> 
> 
I just test this code change by adding the above condition check, and this time, gdb does not crash, but no good information is show, it looks like:

(gdb) r
Starting program: e:\code\test_gdb\a1.exe
[New Thread 268.0x1098]

Program received signal SIGTRAP, Trace/breakpoint trap.
main () at e:\code\cb\test_code\gdbpython-demo\main.cpp:41
41          return 0;
(gdb) p q
$1 = {
  c = {<std::_Deque_base<std::basic_string<char, std::char_traits<char>, std::al
locator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >> = {
      _M_impl = {<std::allocator<std::basic_string<char, std::char_traits<char>,
 std::allocator<char> > >> = {<__gnu_cxx::new_allocator<std::basic_string<char,
std::char_traits<char>, std::allocator<char> > >> = {<No data fields>}, <No data
 fields>}, _M_map = 0xb89e98, _M_map_size = 8, _M_start = "a", _M_finish =
    <error reading variable: Cannot access memory at address 0xbaadf001>}}, <No
data fields>}}
(gdb) python print 1
1
(gdb) p v
$2 = {<std::_Vector_base<std::basic_string<char, std::char_traits<char>, std::al
locator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >> = {
    _M_impl = {<std::allocator<std::basic_string<char, std::char_traits<char>, s
td::allocator<char> > >> = {<__gnu_cxx::new_allocator<std::basic_string<char, st
d::char_traits<char>, std::allocator<char> > >> = {<No data fields>}, <No data f
ields>}, _M_start = 0xb89e70, _M_finish = 0xb89e7c,
      _M_end_of_storage = 0xb89e7c}}, <No data fields>}
(gdb) p a
No symbol "a" in current context.
(gdb) p stdStr
$3 = "std::string value Ref"
(gdb)

You can see, both the queue and the vector does not shown quite well. but std::string can still work well.


> --------------------------------------------------------------------
> BTW: if I build my test code under mingw gcc 4.6.2, then there's no crash here, and "p q" can correctly show the std::queue's contents from pretty printer.
> 
> BTW2: my friend xunxun can test the code under Win7, and it seems  there's no crash.

My friend xunxun is a gdb20111027 cvs version, and it has no crash under Win7.
I just use this gdb20111027 cvs on my WinXP, and it works quite well.

So, the conclusion should be:
This bug is introduced after 20111027, so it is nearly the last week. I hope the developers can find the regression introduced the last week. I'm not familiar with the gdb's source code, but I would like to test for you.

Thanks.
asmwarrior
ollydbg from codeblocks' forum

Re: gdb crash when I try to print a std::queue (Windows)

[陳韋任]

> So, the conclusion should be:
> This bug is introduced after 20111027, so it is nearly the last week. I hope the developers can find the regression introduced the last week. I'm not familiar with the gdb's source code, but I would like to test for you.

  Have you opened a bug report? See http://www.gnu.org/s/gdb/bugs/

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667

Re: gdb crash when I try to print a std::queue (Windows)

[asmwarrior]

On 2011-10-31 16:40, 陳韋任 wrote:
>> So, the conclusion should be:
>> This bug is introduced after 20111027, so it is nearly the last week. I hope the developers can find the regression introduced the last week. I'm not familiar with the gdb's source code, but I would like to test for you.
>   Have you opened a bug report? See http://www.gnu.org/s/gdb/bugs/
>
> Regards,
> chenwj
>
Ok, done.

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

thanks for the hint.

asmwarrior

Re: gdb crash when I try to print a std::queue (Windows)

[xunxun]

I think it's caused by

CVSROOT:	/cvs/src
Module name:	src
Changes by:	pmuldoon@sourceware.org	2011-10-27 09:14:27

Modified files:
	gdb            : ChangeLog
	gdb/python     : py-breakpoint.c py-frame.c py-lazy-string.c
	                 py-symbol.c py-type.c

Log message:
	2011-10-27  Phil Muldoon<pmuldoon@redhat.com>
	
	* python/py-breakpoint.c (bppy_set_enabled): Use TRY_CATCH.
	(bppy_set_task): Ditto.
	(bppy_delete_breakpoint): Ditto.
	* python/py-symbol.c (gdbpy_lookup_symbol): Ditto.
	(gdbpy_lookup_global_symbol): Ditto.
	* python/py-lazy-string.c (stpy_convert_to_value): Ditto.
	* python/py-frame.c (frapy_is_valid): Ditto.
	(frame_info_to_frame_object): Ditto.
	* python/py-type.c (typy_lookup_type): Ditto.
	(typy_getitem): Ditto.
	(typy_has_key): Ditto.
	(typy_richcompare): Use TRY_CATCH.  Do not return Py_NE on error.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.13463&r2=1.13464
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/python/py-breakpoint.c.diff?cvsroot=src&r1=1.27&r2=1.28
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/python/py-frame.c.diff?cvsroot=src&r1=1.20&r2=1.21
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/python/py-lazy-string.c.diff?cvsroot=src&r1=1.9&r2=1.10
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/python/py-symbol.c.diff?cvsroot=src&r1=1.9&r2=1.10
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/python/py-type.c.diff?cvsroot=src&r1=1.26&r2=1.27


Before the commit, my gdb works well.
But I have no time to find out the problem now.

You can open a bug report.



-- 
Best Regards,
xunxun

Re: gdb crash when I try to print a std::queue (Windows)

[asmwarrior]

On 2011-10-31 16:52, xunxun wrote:
> I think it's caused by
>
> CVSROOT:    /cvs/src
> Module name:    src
> Changes by:    pmuldoon@sourceware.org    2011-10-27 09:14:27
>
> Modified files:
>     gdb            : ChangeLog
>     gdb/python     : py-breakpoint.c py-frame.c py-lazy-string.c
>                      py-symbol.c py-type.c
>
> Log message:
>     2011-10-27  Phil Muldoon<pmuldoon@redhat.com>
>     
>     * python/py-breakpoint.c (bppy_set_enabled): Use TRY_CATCH.
>     (bppy_set_task): Ditto.
>     (bppy_delete_breakpoint): Ditto.
>     * python/py-symbol.c (gdbpy_lookup_symbol): Ditto.
>     (gdbpy_lookup_global_symbol): Ditto.
>     * python/py-lazy-string.c (stpy_convert_to_value): Ditto.
>     * python/py-frame.c (frapy_is_valid): Ditto.
>     (frame_info_to_frame_object): Ditto.
>     * python/py-type.c (typy_lookup_type): Ditto.
>     (typy_getitem): Ditto.
>     (typy_has_key): Ditto.
>     (typy_richcompare): Use TRY_CATCH.  Do not return Py_NE on error.
>
> Patches:
> http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.13463&r2=1.13464
>
> http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/python/py-breakpoint.c.diff?cvsroot=src&r1=1.27&r2=1.28
>
> http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/python/py-frame.c.diff?cvsroot=src&r1=1.20&r2=1.21
>
> http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/python/py-lazy-string.c.diff?cvsroot=src&r1=1.9&r2=1.10
>
> http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/python/py-symbol.c.diff?cvsroot=src&r1=1.9&r2=1.10
>
> http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/python/py-type.c.diff?cvsroot=src&r1=1.26&r2=1.27
>
>
>
> Before the commit, my gdb works well.
> But I have no time to find out the problem now.
>
> You can open a bug report.
>
>
>
I did test to check whether this commit introduce the crash problem,
then the result is YES.
see the details in:
http://sourceware.org/bugzilla/show_bug.cgi?id=13363#c5

I'm not quite familiar with gdb's source code, so I can't dig into it
further.

asmwarrior
ollydbg from codeblocks' forum