Hello,
I'm seeing some reports of "write after free" reported by malloc by
peolpe running current. Malloc has become more strict since begining
of June. Let me explain:
Small allocations share a page. e.g. a 4k page will hold 8 512 byte
allocations.
When one such allocation is freed, it will be filled with a "free
junk" pattern, stay for a short while in the delayed free list (and be
subhject to write after free checks) and after that it will be marked
free and it might be allocated again. On a new allocation the write
after free check will also be done. That is the new part of my commit
in June. Another change is that on the allocation of the page
containing chunks, all chunks wil be filled with a "free junk" (0xdf)
patttern.
The change has a consequence: the time span of the "write after free"
checks is much longer, as it can take a long time for a chunk to get
used again.
I do believe the changes itself are correct and can help findiung
bugs in other code.
You can also be set upon a wrong foot: if an out of bounds write on a
adjacent chunk happens and lands in (another) free chunk, upon
allocation of that free chunk it will be reported as a "write after
free" case. It might even be that an allocation that was never
allocated and never freed is still "write after free" because of
"close" out of bounds writes.
I'm thinking how to change the error message to reflect that.
If these extra checks hinder progress, it is possible to swicth them
off using malloc option f (small F).
For general debugging I recommend using malloc option S, is has all
the extra strictness that can be enabled while still conforming to the
malloc API.
Please be aware of these things while hunting for bugs.
-Otto
