Re: mktime/tset - static storage leaks and how cope with them

[Wolfram Gloger]

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.