The scratch allocator could erroneously return a slice
overlapping previously allocated memory for allocation
requests that were smaller than the arena size, but larger
than the amount of free space left in the arena.
- fix the check in mem::scratch_alloc_bytes_non_zeroed
that wasn't routing the request to the backup allocator.
- added concrete reproduction test under tests/issues.
map_file_from_path now passes the appropriate flags on to os.open
instead of always calling it with os.O_RDWR.
It will no longer try to open a file with write permissions if the user
didn't request write access to the file mapping (or vice-versa).
This change was made in order to allow things produced with Odin and using Odin's core library, to not require the LICENSE to also be distributed alongside the binary form.
The last address of "data" is not "cast(uintptr)raw_data(data)+cast(uintptr)size" but
"cast(uintptr)raw_data(data)+cast(uintptr)(size-1)".
The original assert would fail when for example the allocation size requested and the buddy allocator allignment were both 64.
This is always a pointer past the end of the buffer given to
`buddy_allocator_init`, which could be an invalid address. Printing may
result in a segmentation violation.
This didn't take into account the size of the header plus the size of
the allocation itself by virtue of `align_forward_uint`; this could
result in no change if `size` was equal to `b.alignment` because the
number is aligned, and if `actual_size` and `size` ended up being equal,
no additional space would be requested.
This meant that a block would end up being allocated on top of its
buddy's head.
Fixes#3435
It has been discovered that AddressSanitizer does not keep a 1:1 mapping
of which bytes are poisoned and which are not. This can cause issues for
allocations less than 8 bytes and where addresses straddle 8-byte
boundaries.
See the following link for more information:
https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm#mapping
