cferris@ found an issue due to the new Secondary free list behavior
and unfortunately it's completely my fault. The issue is twofold:
- I lost track of the (major) fact that the Combined assumes that all chunks returned by the Secondary are zero'd out apprioriately when dealing with ZeroContents. With the introduction of the freelist, it's no longer the case as there can be a small portion of memory between the header and the next page boundary that is left untouched (the rest is zero'd via release). So the next time that block is returned, it's not fully zero'd out.
- There was no test that would exercise that behavior :(
There are several ways to fix this, the one I chose makes the most
sense to me: we pass ZeroContents to the Secondary's allocate
and it zero's out the block if requested and it's coming from the
freelist. The prevents an extraneous memset in case the block
comes from map. Another possbility could have been to memset
in deallocate, but it's probably overzealous as all secondary
blocks don't need to be zero'd out.
Add a test that would have found the issue prior to fix.
We currently release unconditionally in deallocate. Does this zero-out the memory?
If so, we might only need to zero the first page here, not the whole allocation.