[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mktime/tset - static storage leaks and how cope with them
From: |
Wolfram Gloger |
Subject: |
Re: mktime/tset - static storage leaks and how cope with them |
Date: |
Wed, 9 Oct 2002 16:35:35 +0200 (MDT) |
Hi,
> i'm currently purifying my development environment with respect to storage
> leaks, and found to my very surprise, that mktime leaks 6 mallocs.
>
> Digging into it, i located the problem in tzset.c, which maintains a variable,
> citing:
>
> | struct tzstring_l *tzstring_list;
> |
> | /* Allocate a permanent home for S. It will never be moved or deallocated,
> | but may share space with other strings.
> | Don't modify the returned string. */
>
> Not deallocating allocated storage is a memory leak by definition. Plain and
> simple.
No. Where is the leak here? The allocated storage isn't deallocated
because it can and will be reused by further mktime calls. IOW, there
is still a reference to the allocated memory.
> Now that this screws up my malloc/realloc/free counting,
Well, I'm sorry but you can't expect much from a simple counting
algorithm like that.
> Though in all of these libraries, there is no aparent storage black hole, i
> think that cummulating storage into static variables without providing means
> to globally detect leaks the same time is a very bad style.
No, as you have found this is a very common technique.
> Not knowing any better notion for this, i suggest the name "static storage
> leak" for this kind of memory leaks.
I suggest the name "one-time fixed allocation" for this kind of
non-leak :-)..
> If you have any better idea to cope with this, please let me know, since i
> plan to propose this interface to the maintainers of the other libraries
> listed above. Please especially do so, if you think that my approach to leak
> detection is wrong.
I suggest that you try "valgrind". It has quite comprehensive leak
detection -- I think it can also determine whether there are still
references to allocated chunks. If you must continue with the simple
counting method, I would suggest that you ignore all allocation paths
that are run-through only _once_, and instead concentrate on the paths
that are run through multiple times without corresponding
deallocations.
Regards,
Wolfram.