Re: changes to malloclog to print out neighbouring memory allocations

[christos%astron.com@localhost (Christos Zoulas)]

In article <20081023130947.GF5706%baea.com.au@localhost>,
Brett Lymn  <blymn%baesystems.com.au@localhost> wrote:
>-=-=-=-=-=-
>
>
>I have been working with someone to try and track down what looks to
>be a memory corruption, memory is getting modified on the kernel
>freelist.  They have enabled MALLOCLOG which allows us to track memory
>allocations for the region of interest but I wanted to investigate the
>possibility of there being a "bad neighbour" meaning that the
>object allocated before the one detecting the corruption is being
>overflowed and corrupting memory further along.  To try and catch this
>I modified the MALLOCLOG code to include a neighbour detection which
>checks the logs for allocations where base + size modulo is within a
>"fuzz" factor of the address of interest.
>
>Attached is a patch that does this - the variable malloclog_fuzz
>controls how wide the matching is.  This is a variable so it can be
>tweaked dynamically (via ddb or the like) to broaden or narrow the
>matching range depending how much noise (or lack thereof) is returned.
>
>Useful?  Commit?

Sure, that looks useful.

christos