> On Sun, Sep 24, 2017 at 09:02:58PM -0400, Daniel Micay wrote: > > > > In the end all double frees still will be caught by the actual free > > > code, just with a delay. The delayed free buffer double free check is > > > just a way of catching it as soon as possible to make debugging > > > easier. That's the reason the originla code could just do the check > > > on the slot being replaced only. > > > > > > The only case that could be missed is when the chunk is given out by > > > malloc in between the original free and the double free. But that > > > case never be caught in all circumstances since the delay buffer is of > > > finite size. > > > > > > -Otto > > > > True, the delay buffer currently only guarantees allocations are kept > > out of circulation for one cycle since the random choice is between > > previously freed allocations, never the current one. > > > > It matters more with the other change making half of the quarantine into > > a ring buffer to provide a longer guaranteed delay. I think that makes > > sense as a trade-off vs. an extra bit of entropy from a 2x larger random > > array for a given total quarantine size. It also improves the write- > > after-free detection, especially with a configurable quarantine size, > > which makes it somewhat like the ASan quarantine but with delayed > > detection of write-after-free and only indirect read-after-free > > detection via junk filling (i.e. if something ends up crashing / > > breaking from reading junk instead of what it expected). > > I'm hesitatant to add too much complexity here. Delayed free is to add > extra randomization to the re-use of chunks. Detecting double free is > just an extra. If it can be done cheap, good. But otherwise... > > BTW, you hash function causes too much collisions of chunks, since the n > lower bits of them are zero. Probably best to shift them right by > info->shift bits instead of MALLOC_MINSHIFT.
I'll add my two bits. In the last decade otto's malloc has collected a vast number of 'cheap' checks. The cheap ones are the most important ones, because they can be enabled by default. As such, they expose bugs in software which can be resolved. The mere indication that a piece of software has one corruption bug detected by malloc, tends to indicate it has more, so this can drive auditing focus. However non-cheap checks worry me. They need to be enabled using feature flags. The obvious one is 'S', but now these non-cheap checks impact the people trying to run with 'S' in support of the community; their software gets measureably slower, so some people may stop using 'S'. I think anything beyond O(very small) doesn't have a place here, but we need to hope that other tooling / review / checks should find those. Other malloc's entirely lack these checks, they are relying on other those discovery processes. That doesn't mean our users need to carry the burden fully. And please see: https://arxiv.org/pdf/1709.02746.pdf (I don't like their pre-reserve design, and hope there is opportunity to improve the O(not tiny) parts in otto malloc)
