This is the mail archive of the gdb-prs@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/592: Serious memory leak and slow perf of call foo()/print foo() commands


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


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