Recent Features
| |||||||||||||
Pettenò: Debunking x32 mythsPettenò: Debunking x32 mythsPosted Jun 27, 2012 13:51 UTC (Wed) by nix (subscriber, #2304)In reply to: Pettenò: Debunking x32 myths by gmaxwell Parent article: Pettenò: Debunking x32 myths
The memcheck tool should work fine regardless of what pointer you access the data through.Quite. It's not like memcheck's libVEX CPU emulation knows or cares whether you use a pointer-plus-offset or a direct pointer. It just simulates and spies on the resulting memory accesses.
(Log in to post comments)
Pettenò: Debunking x32 myths Posted Jul 1, 2012 20:47 UTC (Sun) by oak (guest, #2786) [Link]
I wasn't talking about the memory access issues memcheck reports, but it detecting whether the allocated memory is lost or not (--leak-check option).
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) [Link]
memcheck's algorithm should only cause problems if fontconfig is doing multiple allocations and then only storing a pointer to one of them, and referencing the rest via pointer subtraction rather than separate pointers. Since subtraction of pointers to distinct objects is undefined according to the C Standard I think that an incorrect leakage warning is the least you can expect from this.
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.
|
|||||||||||||