[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Tracking allocated memory (was: Tracking memory leaks -- advice needed)
From:       iglio () fub ! it (Pietro Iglio)
Date:       1999-06-23 7:08:15
[Download RAW message or body]



>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 6/20/99, 10:45:33 AM, Stephan Kulow <coolo@itm.mu-luebeck.de> wrote 
regarding Re: Tracking memory leaks -- advice needed:

> Pietro Iglio wrote:
> > I need a way to detect how much memory has been allocated between two
> > execution
> > points. Suppose, for example, that I'm going through the execution
> > with gdb and
> > I have the following example code:
> >
> >    Foo* foo = new Foo(.....);
> >
> >    fee = buildFeeTree(....);
> >
> > I would like to call a function (eg.) get_allocated_memory() from gdb
> > before
> > and after every step to know how many bytes have been allocated by the
> > constructor
> > of Foo and during the execution of buildFeeTree().

> Well, if you use the dmalloc library (just install dmalloc-0.4 and use
> --with-dmalloc in kdelibs), you'll get a function called 
dmalloc_log_stats(),
> which you can call as many times as you want. Unfortunatly it's output
> is a bit more verbose than say one int :)

> Greetings, Stephan

Well, I discovered that you can trace the value of the global variable 
alloc_current,
that stores the amount of memory that has been allocated and not freed 
yet.

Displaying the value of alloc_current during a debugging session has 
been very helpful 
to discover some memory leaks in functions that should not have left 
allocated memory
(just look at the value of alloc_current before and after the 
execution of the function).

Here are some results tracking kpanel memory usage:

  KPanelApp kpapp( argc, argv, "kpanel" );  // allocates 175k !!!

  CORBA::ORB_var m_vORB = 
     CORBA::ORB_init( argc, argv, "mico-local-orb" ); // allocates 6k

  KdedInstance kded( argc, argv, m_vORB ); // allocates 12k

  registry.load();   // allocates 47k

  new KPanel();   // allocates 67k

  kpanel->buildKMenu();  // allocates 104k

... then kpanel enters in the event-loop with 433k allocated. As you 
can see, KApp 
and the registry stuff are allocating about 250k, i.e. more than 50% 
of the memory
allocated for kpanel on startup! I suspect that QApplication is 
largely responsible
for that, isn't it?

-- Pietro

[prev in list] [next in list] [prev in thread] [next in thread]