This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: gdb/592: Serious memory leak and slow perf of call foo()/print foo() commands
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 4 Jul 2002 02:28:01 -0000
- Subject: Re: gdb/592: Serious memory leak and slow perf of call foo()/print foo() commands
- Reply-to: Daniel Jacobowitz <drow at mvista dot com>
The following reply was made to PR gdb/592; it has been noted by GNATS.
From: Daniel Jacobowitz <drow@mvista.com>
To: stcarrez@nerim.fr
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/592: Serious memory leak and slow perf of call foo()/print foo() commands
Date: Wed, 3 Jul 2002 22:22:27 -0400
On Sun, Jun 30, 2002 at 08:27:41AM -0000, stcarrez@nerim.fr wrote:
>
> >Number: 592
> >Category: gdb
> >Synopsis: Serious memory leak and slow perf of call foo()/print foo() commands
> >Confidential: no
> >Severity: serious
> >Priority: high
> >Responsible: unassigned
> >State: open
> >Class: sw-bug
> >Submitter-Id: net
> >Arrival-Date: Sun Jun 30 01:28:00 PDT 2002
> >Closed-Date:
> >Last-Modified:
> >Originator: Stephane Carrez
> >Release: 5.2
> >Organization:
> >Environment:
> i686-pc-linux-gnu
> Using the following gcc (but it's not related to it):
> /usr/lib/gcc-lib/i586-mandrake-linux-gnu/2.96/specs
> gcc version 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)
> >Description:
> There is a serious memory leak when we use the call foo() or
> print foo() commands. The problem shows up clearly with
> C++ programs that have big symbol tables (due to template
> instantiations).
>
> Gdb's process eats 140Mb after each call bar(0).
>
> The C++ prog attached does nothing useful but instantiates
> several STL map templates.
Thanks for the simple testcase. I've spotted a couple of really lame
algorithms in our finding of overloaded symbols; I'll try to overhaul
this code in the next week.
There is no good reason for it to demangle every symbol in the program.
I see two memory leaks in overload_list_add_symbol. And as someone
pointed out last year or so, we should not be forcing a read of all
psymtabs in make_symbol_overload_list either. And upon inspection I'm
not even certain that overload_list_add_symbol _can_ work as it is
written. I'll do some archeology; I suspect a merge bug.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer