Bug 392373

Memcheck determines if the block is reachable from pointers within the root-set, checking for pointed-sized memory locations that are stored into an *aligned* address. This may leads to false positives in case some code, for the sake of memory efficiency or representation locality, packs pointers with other data, effectively storing pointers at unaligned addresses. Note that using memcpy() instead of deferencing the pointer, such a memory layout is perfectly safe even in architectures that do not have support for accessing unaligned memory locations: anyway when this is possible, compilers will translate memcpy with a fixed pointer-size "count" to a load/store operation instead of actually calling the function, so there is not lack of performances most of the times.
An example of code using this trick is an hash table where, instead of storing at each dictionary bucket a single value, we store a blob of prefixed-len keys followed by the respective pointer in a single allocated memory blob: "[3]foo<ptr-for-foo-value>[5]apple<ptr-for-apple-value>". This is similar to chaining but without paying the pointers and new bucket memory cost. In this case, Valgrind will not be able to look for the pointers when they are stored at unaligned offsets, reporting the leak. I imagine that scanning for aligned addresses is faster, because the search space is reduced to 1/8 of what would be otherwise. However this feature could just be opt-in, so that normally Valgrind users will not incur in any penalty. I have no expertise on the internals of Valgrind, but I can imagine that this feature could also be quite simple to add, if there is to change just the step of the search. Thanks for checking this issue. Regards, Salvatore.