gdb 5.2.1?

Daniel Jacobowitz
Fri Jun 28 21:33:00 GMT 2002

On Sat, Jun 29, 2002 at 01:46:21AM +0200, Stephane Carrez wrote:
> Hi!
> Jim Blandy wrote:
> >Andrew Cagney <> writes:
> >
> >>No I've not forgotten.  Just a little distracted :-(
> >>
> >>If anyone knows of a bug or fix they want in 5.2.1 then please see
> >>about pulling it in during the next 24 hrs.
> >>
> >
> >I wish GDB didn't use so much memory.  If you could pull that in
> >during the next 24 hours, that would be incredibly great.
> >
> So do I!
> For a big C++ program gdb's process goes above 100Mb and increases by 350Mb
> each time I do a 'call foo()'.  Pretty unusable (it's also incredibly slow).
> Interestingly it seems only bound to calling a function from gdb.
> I found this in stabsread.c (and it is one place that allocates some
> memory while I see my pb).
>       /* If this symbol is from a C++ compilation, then attempt to cache the
>          demangled form for future reference.  This is a typical time versus
>          space tradeoff, that was decided in favor of time because it sped 
>          up
>          C++ symbol lookups by a factor of about 20. */
>       SYMBOL_INIT_DEMANGLED_NAME (sym, &objfile->symbol_obstack);
> Can this be deactivated?

It shouldn't need to be.  We shouldn't be rereading symbols at a
call foo().  I have a good hunch why it's so slow - something that was
mentioned on the list but never fixed - but not as to why it leaks
memory.  If you can produce a testcase I'd greatly appreciate it.

Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

More information about the Gdb mailing list