[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic