This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Infinite loop in make_cv_type
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: Richard dot Earnshaw at arm dot com, gdb-patches at sources dot redhat dot com
- Date: Fri, 22 Feb 2002 19:06:48 +0000
- Subject: Re: Infinite loop in make_cv_type
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
This gets even more bizarre. I set a some breakpoints, one on
make_cv_type, and another on dbx_next_symbol_text. Now at the point of
making the cv variant for the first time the previous call to
dbx_next_symbol_text had returned
$736 = 0x509b43 "__comp_ctor::811:_ZNSt14_STL_auto_lockC1ERSt15_STL_mutex_l
ock;2A.;__base_dtor::813=#810,21,812,21;:_ZNSt14_STL_auto_lockD2Ev;2A.;\\"
(top-gdb)
But going up the stack from make_cv_type we find:
(top-gdb) up
#1 0x000dac20 in read_type (pp=0xefbfca04, objfile=0x297000)
at /nfs/sun18/work/rearnsha/gnusrc/src/gdb/src/gdb/stabsread.c:2682
2682 type = make_cv_type (TYPE_CONST (type), 1, type,
(top-gdb) p *pp
$737 = 0x509c1d ",21;:_ZNSt14_STL_auto_lockaSERKS_;0A.;\\"
But this is part of the text that is returned by the next call to
dbx_next_symbol_text...
(top-gdb) c
Continuing.
Breakpoint 12, dbx_next_symbol_text (objfile=0x297000)
at /nfs/sun18/work/rearnsha/gnusrc/src/gdb/src/gdb/dbxread.c:999
999 }
$738 = 0x509bc6 "__comp_dtor::813:_ZNSt14_STL_auto_lockD1Ev;2A.;operator=::
814=#810,21,812,815=&816=k810,21;:_ZNSt14_STL_auto_lockaSERKS_;0A.;\\"
Any suggestions as to how the stabs reader might be getting ahead of
itself? Is there another function that might be returning the stabs
string? I don't think dbx_next_symbol_text has ever returned this
earlier...
R.