This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb 5.2.1?
On Sat, Jun 29, 2002 at 01:46:21AM +0200, Stephane Carrez wrote:
> Hi!
>
> Jim Blandy wrote:
>
> >Andrew Cagney <ac131313@ges.redhat.com> 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