Recent Features
| |||||||||||||
Pettenò: Debunking x32 mythsPettenò: Debunking x32 mythsPosted Jun 26, 2012 17:56 UTC (Tue) by oak (guest, #2786)In reply to: Pettenò: Debunking x32 myths by butlerm Parent article: Pettenò: Debunking x32 myths
> Changing the compiler to support smaller pointers is much more effective
> than making the code changes required in a large code base to use offsets > instead, changes that would typically make the source code less readable, > less portable, and less type safe than it was before.
Fontconfig uses offsets instead of pointers. That is really annoying in a shared library because every program linking that (even indirectly like all GUI apps do) gets then bogus memory leak reports etc from Valgrind as Valgrind cannot heuristically determine that offset is a valid "pointer" to an allocation...
(Log in to post comments)
Pettenò: Debunking x32 myths Posted Jun 27, 2012 12:14 UTC (Wed) by gmaxwell (subscriber, #30048) [Link]
Huh? That shouldn't be the case at all. The memcheck tool should work fine regardless of what pointer you access the data through. Have an easily reproduced example? The fontconfig things I thought to try here are running clean in valgrind for me.
I googled around and found cases of people complaining about valgrind reports in older versions of it— but those cases sure appeared to be reads straddling distinct calls to malloc, which isn't valid (even if the memory happened to appear contiguous, IIRC you're not permitted to read across the boundary because it could be in separate segments).
Pettenò: Debunking x32 myths Posted Jun 27, 2012 13:51 UTC (Wed) by nix (subscriber, #2304) [Link] 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.
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.
Pettenò: Debunking x32 myths Posted Jun 27, 2012 12:26 UTC (Wed) by gioele (subscriber, #61675) [Link]
> Fontconfig uses offsets instead of pointers.
It would be much better if there was a shared library or just a set of macros in headers (CCAN?) that C/C++ projects could reuse without dealing with dangerous pointer manipulations.
|
|||||||||||||