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

[Lars Doelle]

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.


Now that this screws up my malloc/realloc/free counting, i finally worked 
around the problem using timegm, which, due to the man page, is not be used 
at all.


Well knowing how annoying bug reports like this one can be, please understand 
that i'm using quite a number of libraries here, which all insist of 
maintaining never released storage in static variables, making it more or 
less impossible to find whether there are storage leaks in my program or not.

To detect these, i use the hooks in malloc/realloc/free, simply counting 
mallocs and frees. Now stl for instance comes with its own alloc stuff, which 
can be worked around using malloc_alloc, but with a significant speed 
penalty. For a leak in glibc see above. As for Qt, i can report 7000 
something missing objects after creating/deleting a QApplication, with no 
workaround, yet. Sigh.

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. As one sees, not 
even the glibc can be trusted not to have leaks and in times where lots of 
libraries go into one single program, reducing oneself to local leak 
detection (e.g my_malloc or overloaded new) and trust otherwise would not 
really help to create any assertion with respect to dynamic storage balance.

Not knowing any better notion for this, i suggest the name "static storage 
leak" for this kind of memory leaks.


I do not like to close the letter without proposing any way to fix things, and 
i suggest that glibc should include an interface (count and release of such 
objects) if you really need to allocate permanently into static variables.

This would mean to provide a user interface for __libc_subfreeres (and 
possible friends) together with a count (via a function). The count could be 
used to adjust malloc counts accordingly and the clean-up function could be 
called in the end of the program to get a real malloc count of zero, which i 
find a test so basic, that any properly crafted program should happily 
survive it.


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.


Thanks
-lars