Cores from a customer revealed :
(1) a memory corruption issue
(2) a free list inconsistency

There's a separate bug tracking the memory corruption issue.
This bug is filed because it is possible that the free list
inconsistency may be orthogonal and independent of the
memory corruption issue.

The core files of significance are the ones from 9/18 and 9/22.

The free list inconsistency may be described thus:

  . the free lists in question are those in the small size lists
    indexed from a table of sizes
  . each list has a head and tail pointer to the list of free blocks
    and a count that tracks the list population
  . in both cases in question, the lists were empty but the
    counts indicated non-zero counts

Targeted testing with assertions to check for the correspondence of
counts and list lengths are in progress. It is also possible to
make the code "self-healing" in that if an inconsistency is discovered
it can be fixed without crashing, but at the cost of some performance.
See Evaluation section.

The Synopsis field is accordingly being changed to reflect the work in this
CR from:-

CMS: free list inconsistency in core file

to:-

CMS: sharpen asserts related to free list consistency and locking