Re: [patch] fix for infinite recursion in lookup_symbol

[Fernando Nasser <fnasser@cygnus.com>]

Jim, 

You saved my life!

This causes Insight to crash.  One case I saw is that there were C++ methods
starting with "main", so the look for main to show in the Source Window would
cause a memory exhaust situation.  The other case is when a the Variable Balloons
try to show some overloaded symbol and it also goes into loop.


TO THE INSIGHT LIST FOLKS WHO WERE HAVING THOSE PROBLEMS: Can you please
try Jim's patch and let us know if it fixed your problems?  Thanks.

Fernando


Jim Ingham wrote:
> 
> Hi, all,
> 
> The following patch fixes an infinite recursion in the variable lookup
> code for C++ objects that are specified in mangled form.  The old code
> would take the mangled name into lookup_symbol, unmangle it, and then in
> this bit pass the mangled name BACK to lookup_symbol, which would
> unmangle it and come right back here...  Not a good thing.  The bug
> crept in when lookup_symbol was broken up into lookup_symbol and
> lookup_symbol_aux, the correction is clearly what was meant.
> 
> 2001-01-09  James Ingham  <jingham@inghji.apple.com>
> 
>          * symtab.c (lookup_symbol_aux): Call lookup_symbol_aux to
> lookup a
>          mangled symbol rather than recursing into lookup_symbol, since
> this
>          will just re-unmangle the name & call lookup_symbol_aux -
> leading to
>          an infinite recursion.
> 
> Index: symtab.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/symtab.c,v
> retrieving revision 1.15
> diff -c -w -r1.15 symtab.c
> *** symtab.c    2000/09/04 08:29:25     1.15
> --- symtab.c    2001/01/12 19:29:21
> ***************
> *** 754,760 ****
>              {
>                /* This is a mangled variable, look it up by its
>                   mangled name.  */
> !             return lookup_symbol (SYMBOL_NAME (msymbol), block,
>                                      namespace, is_a_field_of_this,
> symtab);
>              }
>            /* There are no debug symbols for this file, or we are looking
> --- 754,760 ----
>              {
>                /* This is a mangled variable, look it up by its
>                   mangled name.  */
> !             return lookup_symbol_aux (SYMBOL_NAME (msymbol), block,
>                                      namespace, is_a_field_of_this,
> symtab);
>              }
>            /* There are no debug symbols for this file, or we are looking

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From nsd@redhat.com Fri Jan 12 12:43:00 2001
From: Nick Duffek <nsd@redhat.com>
To: ac131313@cygnus.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] spelling corrections
Date: Fri, 12 Jan 2001 12:43:00 -0000
Message-id: <200101122051.f0CKpYT04311@rtl.cygnus.com>
References: <3A5ED35A.B41E9304@cygnus.com>
X-SW-Source: 2001-01/msg00094.html
Content-length: 70

On 12-Jan-2001, Andrew Cagney wrote:

>yes.

Thanks, committed.

Nick
From nsd@redhat.com Fri Jan 12 12:48:00 2001
From: Nick Duffek <nsd@redhat.com>
To: ac131313@cygnus.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] gdbarch.sh: multi-arch PARM_BOUNDARY
Date: Fri, 12 Jan 2001 12:48:00 -0000
Message-id: <200101122055.f0CKtkD04372@rtl.cygnus.com>
References: <3A5EF5A4.7C7EF047@cygnus.com>
X-SW-Source: 2001-01/msg00095.html
Content-length: 299

On 12-Jan-2001, Andrew Cagney wrote:

>This is a new architecture method.

No, it's an existing method, I'm just multi-arching it.

>Can you explain its intended purpose.

From gdbint.texinfo:

  If non-zero, round arguments to a boundary of this many bits before
  pushing them on the stack.

Nick
From nsd@redhat.com Fri Jan 12 13:32:00 2001
From: Nick Duffek <nsd@redhat.com>
To: ac131313@cygnus.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] new BASEREG_ADDRESS macro
Date: Fri, 12 Jan 2001 13:32:00 -0000
Message-id: <200101122140.f0CLeYF04411@rtl.cygnus.com>
References: <3A5EF913.DD51B9E2@cygnus.com>
X-SW-Source: 2001-01/msg00096.html
Content-length: 370

On 12-Jan-2001, Andrew Cagney wrote:

>Can you think of a name other than BASEREG_ADDRESS() that better reflects
>the transformation being performed?

>my first guess was that BASEREG_ADDRESS returns the address of the
>register BASE in, at or near ``addr''.

Yes, I can see how one might think that.  How about
ADJUST_BASEREG_ADDRESS?  Other suggestions welcome.

Nick
From nsd@redhat.com Fri Jan 12 13:36:00 2001
From: Nick Duffek <nsd@redhat.com>
To: ac131313@cygnus.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] New register definition interface
Date: Fri, 12 Jan 2001 13:36:00 -0000
Message-id: <200101122144.f0CLi0104421@rtl.cygnus.com>
References: <3A5F09B3.93555F06@cygnus.com>
X-SW-Source: 2001-01/msg00097.html
Content-length: 399

On 12-Jan-2001, Andrew Cagney wrote:

>At a guess the cli/* change is independant of the file reg.c.

It depends on regs.c, but not vice versa.  So yes, it could have been a
separate add-on patch.

>Assuming it is it should go in per fixes from Fernando and (private)
>notes from me.

As Fernando said, he's approved it, but I'd be interested in hearing
whatever additional comments you have.

Nick
From jingham@apple.com Fri Jan 12 14:03:00 2001
From: Jim Ingham <jingham@apple.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Fri, 12 Jan 2001 14:03:00 -0000
Message-id: <200101122203.OAA20207@scv1.apple.com>
References: <Pine.LNX.4.10.10101121507570.8389-100000@www.cgsoftware.com>
X-SW-Source: 2001-01/msg00098.html
Content-length: 1351

Daniel,

Well, while you are waiting, it might be nice to check in fixes for some 
of these, since they are pretty simple fixes, and the bugs are pretty 
annoying (in this case it causes gdb to crash, and people tend to REALLY 
hate it when their debugger crashes).  It wasted a couple of days of my 
time chasing it down, and apparently a couple of days of Fernando's time 
as well.

Jim

On Friday, January 12, 2001, at 12:10 PM, Daniel Berlin wrote:

>
>
> On Fri, 12 Jan 2001, Jim Ingham wrote:
>
>> Hi, all,
>>
>> The following patch fixes an infinite recursion in the variable lookup
>> code for C++ objects that are specified in mangled form.  The old code
>> would take the mangled name into lookup_symbol, unmangle it, and then 
>> in
>> this bit pass the mangled name BACK to lookup_symbol, which would
>> unmangle it and come right back here...  Not a good thing.  The bug
>> crept in when lookup_symbol was broken up into lookup_symbol and
>> lookup_symbol_aux, the correction is clearly what was meant.
>
> This was already known, and we are still waiting for Jim Blandy to 
> make a
> decision whether we should revert the binary searching symbol lookup for
> C++ stuff or  not.
> If we decide to stay with the non-linear symbol lookup, i'll fix the 
> bugs,
> as i already have patches for most of them (there aren't many).
>
> --Dan
>
From dberlin@redhat.com Fri Jan 12 17:52:00 2001
From: Daniel Berlin <dberlin@redhat.com>
To: Jim Ingham <jingham@apple.com>
Cc: Daniel Berlin <dberlin@redhat.com>, <gdb-patches@sources.redhat.com>
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Fri, 12 Jan 2001 17:52:00 -0000
Message-id: <Pine.LNX.4.31.0101122049230.14785-100000@www.cgsoftware.com>
References: <200101122203.OAA20207@scv1.apple.com>
X-SW-Source: 2001-01/msg00099.html
Content-length: 873

On Fri, 12 Jan 2001, Jim Ingham wrote:

> Daniel,
>
> Well, while you are waiting, it might be nice to check in fixes for some
> of these, since they are pretty simple fixes, and the bugs are pretty
> annoying (in this case it causes gdb to crash, and people tend to REALLY
> hate it when their debugger crashes).

I can't without approval from Jim anyway. I'm still waiting for approval
for some simple changes I submitted a few weeks ago to be approved as
well, i don't want to juggle that many outstanding patches.

>  It wasted a couple of days of my
> time chasing it down, and apparently a couple of days of Fernando's time
> as well.
Sorry to hear that. If you look back, ti was reported in either november
or december, and a huge discussion ensued.
Wish there was something more I could do, but it's not my area of
maintenance, so all I can do is submit patches.