Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
AFAIK Valgrind scans at the end through the program's memory to see whether there are still valid pointers to the still allocated memory, before it reports what is lost.
According to Memcheck manual:
It considers only "pointers" that point to start of an allocated block, or to middle of it (like e.g. at least earlier Firefox JS engine did as it used some of the bits to store object info).
Because fontconfig stores allocations as offsets, not as pointers, they don't point to allocated memory and thus memcheck considers (at least some of them) lost.
Pettenò: Debunking x32 myths
Posted Jul 1, 2012 22:20 UTC (Sun) by nix (subscriber, #2304)
However, what it actually appears to be doing is malloc()/realloc()ing an arena and then referencing objects *inside this arena* via offsets. This is perfectly valid (it's just a C array): the benefit is increased speed, the cost is increased memory usage if some of the elements are unused, and of course that valgrind cannot automatically detect leakage of elements within that array, only leakage of the array as a whole (if FcObjectSetAdd() gets called but then the array is never FcObjectSetDestroy()ed). This is of course entirely permissible: a whole lot of programs using a single fontset might create an FcObjectSet(), store it statically, and then never bother to destroy it, even on exit. I suspect that this behaviour of not freeing allocated storage on exit (particularly on abnormal exit) is near-universal among Unix programs: I know I've done it many times.
The moral is to only expect leak detectors to work on programs that have actually been designed in that expectation (often with a compilation flag to force them to free all storage on exit -- and even then it is unlikely they will bother to free anything on abnormal exit). Such freeing is a waste of time unless you're running a leak detector, is code that is useless if you're not running a leak detector, and if you mess it up you might cause a double-free(), and thus a security hole, where none was before. So it is not surprising that most people don't do it.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds