On Jul 14, 2005, at 8:14 PM, Tom Bernard wrote:
I see myself as closer to "newbie" than "expert" so please salt the
following to taste: Why are you interested in byte patterns that point to
the middle of an allocation?
It's entirely possible to not have any pointers to the beginning of the block, and still be able to successfully free the block later. As a trivial example, suppose you're implementing your own memory-allocation system on top of the system-provided malloc(). You might want to do this as a performance optimization, or to make it easier to track down leaks (!), or various other reasons.
Your library might get a request for X bytes of memory, and fulfill that request by using malloc() to allocate X bytes, plus enough extra space for some record-keeping overhead. You then would store the bookkeeping information at the beginning of the block, and return a pointer from your malloc()-replacement that points some fixed distance into the block you originally allocated (after the bookkeeping information).
When the client program tries to free the memory, you take the pointer they pass to you, subtract the size of the bookkeeping information, then pass that to the system's free(). At no point after the initial malloc() call do you have a pointer to the start of the block. So, it's reasonable for "leaks" to consider byte patterns that are equivalent to addresses inside the block as possibly indicating that the program has an active pointer pointing into the block.
Having said that, I'd be willing to bet that there are VERY few situations where a typical C program has a half-megabyte difference between the start of a block and the only pointer into that block. The obvious enhancement that could be made in leaks would be to add a command-line parameter to set the amount of "slop" allowed in potential pointer values during the scan. It could default to something fairly small, and be adjustable up and down to adjust the optimism/pessimism of the report.
-Mark