4 ms·
Instead of switching to the debug allocator, might it instead be possible to teach ASAN about the pool allocator? I think I did this at some point in the past
by nkurz 8y ago
Instead of switching to the debug allocator, might it instead be possible to teach ASAN about the pool allocator? I think I did this at some point in the past for Valgrind. I don't know if it would be sufficient, but with ASAN it's at least possible to "poison" and un-poison memory manually with macros: http://blog.hostilefork.com/poison-memory-without-asan/ http://blog.hostilefork.com/poison-memory-without-asan/
- maxlybbert 8y agoI really like APR. While pooled allocation isn’t always the best approach, it makes a lot of sense in server software, and reduces the risk of many classic memory problems (e.g., I don’t have to worry whether I pair 1000 mallocs with 1000 frees; it’s acceptable to pair 1000 apr_pallocs with a single apr_pool_free). ASAN is certainly helpful when using classic memory management techniques, but since so much C code uses custom memory management of some kind, it has to handle more than malloc and free. I certainly hope people improve ASAN instead of abandon things like memory pools. I would consider “malloc and free with ASAN” to be a step down from APR’s pools.
- shereadsthenews 8y agoASAN does handle this. As nkurz noted, custom allocators need only poison/unpoison memory regions to benefit from ASAN and MSAN. For example see how the absl "SwissTable" does: https://github.com/abseil/abseil-cpp/blob/master/absl/container/internal/raw_hash_set.h#L1587 https://github.com/abseil/abseil-cpp/blob/master/absl/contai...
- caf 8y agoYes, Valgrind has support for annotating memory pool operations: http://valgrind.org/docs/manual/mc-manual.html#mc-manual.mempools http://valgrind.org/docs/manual/mc-manual.html#mc-manual.mem...