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

List:       kde-devel
Subject:    Re: Thoughts about a memory leak tool
From:       Stephan Kulow <coolo () kde ! org>
Date:       2001-01-20 10:48:20
[Download RAW message or body]

Enno Bartels wrote:
> 
> Hi everybody
> 
> I was thinking about a memory leak tool in kde
> and how to integrate it.
> 
> Because some memory leaks are found after long run
> or only if an application is eating all the memory.
> So It would be nice to find them early in the first development
> circle.
> 
> Thoughts:
> -------
> I you want to search memory leaks at runtime
> there should be a new ./configure switch like
> -enable-memleaksearch
> And it would do all to add the memory leaks search
> includes, libs,  and overridden function we would need for this.
> 
> So if a mem leak is registered for example by an overridden
> function in c++ the bug-detektion-konqy
> window should appear:
> The should be a new radiobutton "memory leak"
> that should be switch on by default by this error case.
> So that an error discription with line number and programm
> name could be send to bugs.kde.org.
> 
> But I think there should be a button somewhere to
> disable this memory leak detektion at runtime, because
> you will allways get this messages if you use a
> programm with an memory leak.
> Or another mechanism - like first time detection
> of an memory leak should only show the bug-dialog ?!?
> 
> Technical infos (small):
> -----------------
> I have seen that there is an programm that can
> seach for memory leaks at runtime at GNOME.
> I did forget the name of that programm and  I couldn't
> find it again :-((((
> 
> There is a memory profiler for malloc
> called "ccmalloc".
> http://www.galstar.com/jmccorm/leak
> 
> There is a discription about overridden functions in c++
> at
> http://www.flipcode.com/tutorials/tut_memleak.shtml
> Can we override new and delete in c++ for the purpose ??
> .......
> 
> I don't know how this can be done for kde
> and
> I don't know  if it is ingenious (of course it is complicated) :-(((
> 
> but we should think about this and if we get less
> coded memory leaks - this thought would be right. :-))))
> 
> Now - what do you think ??
> 
I'm afraid you never really hunted memory leaks :)
First: it can't be done at run time, you have to exit the application
or you need some kind of garbage collection to know what memory areas
have been lost. But if you have garbage collection you don't care for
memory leaks any longer. This would be the best option anyway :)

Then most lost memory you will find with such tools isn't really lost,
but well hidden or never meant to be freed because of static scope.
And then a simple QObject allocates about 7 or 8 different blocks
and if the main window isn't freed you get a memory leak of about
700 blocks with 1400 bytes (numbers are out of air), but these numbers
are useless unless you have a tool understanding the code and telling
you, that the one new isn't freed and the rest belongs to it.

All in all: dream on, it simply isn't that easy.

Greetings, Stephan
-- 
It's my true belief that people having wishes for the bug report tool
and report it to the author haven't got the idea behind open source.
                                             anonymous KDE developer
 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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