You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've found two bugs in the scratch allocator (memory.cpp):
If the ring buffer head (_allocate) ends up exactly at the end of the buffer after a call to allocate, it will never be reached by the while-loop in deallocate - the last condition in that loop checks equality with _end and wraps around to _begin - resulting in an infinite loop.
This is fixed by if (_allocate == _end) { _allocate = _begin; } before returning.
Allocating more memory than available incorrectly returns an OOB pointer if the ring buffer is otherwise empty, because the check is based on in_use(p), which immediately returns false if _free == _allocate.
This can be fixed by extending the condition to if (p > _end || in_use(p)).
The text was updated successfully, but these errors were encountered:
As a follow up, there is at least one additional bug but i haven't tracked it down, the symptoms are misdiagnosed double-frees and memory corruption. I wouldn't recommend using this allocator
I've found two bugs in the scratch allocator (memory.cpp):
If the ring buffer head (
_allocate
) ends up exactly at the end of the buffer after a call to allocate, it will never be reached by the while-loop in deallocate - the last condition in that loop checks equality with_end
and wraps around to_begin
- resulting in an infinite loop.This is fixed by
if (_allocate == _end) { _allocate = _begin; }
before returning.Allocating more memory than available incorrectly returns an OOB pointer if the ring buffer is otherwise empty, because the check is based on
in_use(p)
, which immediately returns false if_free == _allocate
.This can be fixed by extending the condition to
if (p > _end || in_use(p))
.The text was updated successfully, but these errors were encountered: