On Wed, 2016-06-01 at 10:19 -0700, John Reiser wrote: > On 06/01/2016, Marshall Lochbaum wrote: > >>From my perspective I have attempted to use Valgrind as intended, and it > > fails to provide the single most important piece of information for > > diagnosing a use-after-free error. I'm having difficulty understanding > > why anyone would even find the current output useful--it simply states > > that the offending block was allocated from the memory pool. The actual > > information is clearly accessible to Valgrind, and it refuses to show > > it! Even if this is only the default behavior, it strikes me as > > completely insane. > > > > Marshall >
> It seems to me that users of a custom pool allocator should appreciate > that memcheck integrates as well as it does. After that, a pool allocator > that has good usability will have an easy mechanism for reverting > to ordinary malloc+free, for which memcheck provides excellent diagnosis. Yes, having a way to revert to standard malloc/free (e.g. using a compile time option) will for sure be the best way to have the 'standard excellent' diagnosis. Diagnostics with custom pools are a lot more limited: * less precise or absent malloc/free stack traces (as you have seen) * no redzone (so no buffer under/over-flow detection). That being said, I am the last one that has modified that area of the code, so here are some explanations about the difficulty of handling properly custom pool allocator blocks. Valgrind maintains a list of malloc-ed blocks, and a list of (recently) freed blocks (configured with --freelist-vol= and --freelist-big-blocks=) For 'normal' blocks (handled with malloc/free), a byte of memory will be either in the free list or on the malloc list, but never on both lists at the same time. For 'custom' blocks, the situation is a lot more complex: when a block is freed, valgrind stores it as part of the freed block list. However, nothing forbids the custom block allocator to directly re-use this block for the next allocation. valgrind does not have a full description of the way the custom pool works. It just takes note of what is freed, and stores it in the freed list. It also takes note of what is allocated, and stores it in the malloc list. When a new custom block is malloc-ed, valgrind does not re-scan the freed list to try to clean it from the pieces of memory that the custom pool has re-used to provide the new block (that would certainly be very costly in terms of cpu, and is not clear that this can be implemented correctly for all pools). So, in summary, for custom pool, the same byte of memory can be (possibly) in one custom malloc-ed block, and 0, 1 or more free-d blocks. The description of an error has space to report 2 stack traces. To fully report all possible blocks that are the possible source of an error, an error should have a list of stacktraces, each associated with a certain block. Taking all these limitations into account (and including the fact that properly/fully support all kinds of custom pool would be a lot of effort), the current code does some effort to report somewhat the fact that the same byte of memory can be considered both malloc-ed and free-d. Also, in your case, there is an additional difficulty: the pool memory itself is allocated using the standard malloc. So, that means that a byte of memory will *always* be found via this malloc 'main' block, and then might be found in one 'custom malloc-ed' block, and potentially in several free-d blocks. The "recently re-allocated block" is a (somewhat) desperate attempt to report some more info than just : 'this memory is on a freed block' or 'this memory is on a malloc block' (which might be the main block or the custom malloc block, depending on the order valgrind will find the first one). So, in summary: yes, the custom pool support has a lot of weaknesses. Yes, an error description is limited to 2 stack traces. It might be possible to improve all this, but not straightforward to generalise. Moreover, this cannot slow down the normal/usal case of the classical malloc/free. Maybe what could be done is to give priority to the 'smaller/inner' malloc-ed block, when the same byte of memory is found via 2 different blocks (i.e. the 'main' block, and the custom block). Then if also found on a freed block, report the mallock stack trace of the first block, and the free stack trace of the second block. That is however not straightforward, to at the end still end up with an inferior diagnosis, compared to standard malloc/free. Hoping this (long) explanation clarifies a little bit Philippe ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
