It is not clear to me that this has been a waste of time. If \_msize() is part of the regular allocation API, then either its contract is not being met or SQLite has no business writing outside the limit its return imposes. Yet a name like '\_msize' with its leading underscore is unlikely to be part of the same published API as malloc(), realloc() and free(), and reliance upon it by SQLite is arguably incorrect. I believe this issue deserves the attention of the SQLite developers, more so now that you have shown a simple repro scenario. Perhaps you could state what allocator debug tool/package you use to help induce this problem. If you were to edit the subject, to contain the word 'BUG', it would be more likely that one of the SQLite developers will reexamine the use of \_msize(). It may be a bug in the allocator debug aid, but I doubt it. More likely is that the return from \_msize() should not be interpreted as it has been to give the go-ahead to overwriting that guard zone. Should one of the developers look into this, [this \_msize\_dbg() doc](https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/msize-dbg?view=vs-2017) should be consulted. It specifically states the very behavior which produced the OP's issue, saying "but \_msize\_dbg adds two debugging features: It includes the buffers on either side of the user portion of the memory block in the returned size". To me, this clearly indicates that the "user portion" bounds cannot be inferred from the \_msize() return, at least not without some extra work to account for the guard bytes.