From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: Jim Ingham Cc: gdb-patches@sources.redhat.com, insight@sources.redhat.com Subject: Re: [patch] fix for infinite recursion in lookup_symbol Date: Fri, 12 Jan 2001 12:13:00 -0000 Message-id: <3A5F6548.A54F0B6C@cygnus.com> References: <200101121935.LAA03678@scv2.apple.com> X-SW-Source: 2001-01/msg00093.html 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 > > * 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 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 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 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 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 To: Daniel Berlin 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: 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 To: Jim Ingham Cc: Daniel Berlin , Subject: Re: [patch] fix for infinite recursion in lookup_symbol Date: Fri, 12 Jan 2001 17:52:00 -0000 Message-id: 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.