Re: how can I trust glib when it has so manymemleaks?
- From: Lars Hallberg <lah micropp se>
- To: gtk-list redhat com
- Subject: Re: how can I trust glib when it has so manymemleaks?
- Date: Thu, 18 Mar 1999 12:44:01 +0100
On Thu, Mar 18, 1999 at 10:34:42AM +0000, Ionutz Borcoman wrote:
>
> GLib-INFO: 2160 bytes in use
>
> The same ammount of memory that ccmalloc used to found. Now ccmalloc
> claims all the allocated is garbage and nothing is freed. How can I
> interpret these readings ?
Everything is OK!
> A functions that frees memory managed by glib would be more than
> wellcome. Or a change in the g_mem_profile to say: "xxx memory manged
> internaly by glib. this is not mem leak" Or something similar.
the 'xxx memory managed internal by glib' might be missleading as
glib only manage memory while the program runs. When the the program
Exits, all memory is taken back by the OS. Glib do not explicity
free this memmory (probabl) becuse tha OS can do a better job att
it and the OS must do it anyway (if the OS rely on the program to
free its memmory it will hardly be stable ;-)
Making a function that frees all glib memory might be good for
automated testing that simply veryfy 0 leak on many, many programs.
I'm not sure it is worth the effort...
If You test manaly, it is sufficient to compare what Your tool
report leeking with what g_mem_profile() reports delebaritly
leavs for the OS to free. If the amount maches Your code leaks
nothing.
Well, Youre code might leek memory allocated thru glib but that
will showe up as suspisiusly big figures on the g_mem_profile().
Possably g_mem_profile() can differntiate between memmory that is
allocated but 'free' or internaly used an memory allocated by
the users code? If not, that is probably the right spot to hack
glib..... Best luck ;-)
HTH /Lars
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]