On Sun, Sep 03, 2023 at 09:21:18AM +0200, Otto Moerbeek wrote: > 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).
Oops, that should be j (small J). > > 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 >
