This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]