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
Changed the check from `bytes` to `err` for safety's sake, too.
This will prevent the potential bug of allocating non-zero memory, then
doing a zeroed resize, which will result in having garbage data in the
initial half.
The backup allocator is set at `init` and must stay the same for the
lifetime of the Scratch allocator, as this allocator is used to free all
`leaked_allocations`. Changing it could lead to a situation where the
wrong allocator is used to free a leaked allocation.
This will cause an error if the memory being resized was not the last
allocation, as should be expected according to the description that this
"acts just like stack_free."
1. The size was being adjusted for the alignment which does not make any
sense without the context of the base pointer. Now we just add the
`alignment - 1` to the size if needed then adjust the pointer.
2. The root pointer of the last allocation is now stored in order to
make the free operation more useful (and to cover the right memory
region for ASan).
3. Resizing now only works on the last allocation instead of any address
in a valid range, which resulted in overwriting allocations that had
just been made.
4. `old_memory` is now re-poisoned entirely before the resized range is
returned with the new range unpoisoned. This will guarantee that
there are no unpoisoned gaps.
Fixes#2694
This fixes an issue where a call to close could intercept the dance
between send and recv, causing send to report incorrectly that a value
was not transmitted (when it actually was).
This commit makes send behave the same as recv: that the call will
return false if the channel is closed while a thread is waiting on the
blocking operation.
Prior logic would have send return true even if the channel was actually
closed rather than read from.
Docs adjusted to make this clear.
Tests added to lock in this behaviour.
This changes the semantics of try_send to be consistently non-blocking.
That is, if the buffered is full OR there are no readers it returns
false.
The previous behaviour was such that it would block in the latter case
of no reader, and it would wait for a reader. That is problematic
because it produces inconsistent behaviour between buffered and
unbuffered channels which is astonishing and adds complexity to the
caller.
To illustrate the problem with the old behaviour, consider the
try_select operation: if a send-channel happens to be unbuffered the
try_select (which wants to never block) can now block, that unbuffered
send channel is selected (at random) and there is no reader on the other
side. Thus we have unpredictable blocking behaviour, which breaks the
guarantee that try_select never blocks.
If you want a blocking send you can just call "send" (the blocking
variant).
In addition, there is some reader/writer math done inside
can_{send,recv} such that they only report true if there is sufficient
reader/writer capacity. If there is contention we need to ensure that
each reader is paired to exactly one writer.
Consider try_send: if there is a single reader we can send. If there is
a single reader and a single writer, then we cannot send, as that reader
will be paired with the existing writer. Therefore can_send is only true
if there are more readers than writers at the time of check.
NOTE: The original tests don't need to use wait-looping with thread.yield()
or heuristic sleep. Instead we can just use blocking channel operations
rather than non-blocking operations.
This is necessary because we need to allow the test guarantee against a
rare condition: where a third-party thread steals a value between the
validity checks can_{send,recv} and the channel operation
try_{send,recv}.
Fixes a TOCTOU where the channel could be used between the call to
can_{recv,send} and {recv,send} causing an unexpected blocking
operation.
To do this we use the non-blocking try_{recv,send} and retry the check
in a loop. This guarantees non-blocking select behaviour, at the cost of
spinning if the input channels are highly contended.
Signed-off-by: Jack Mordaunt <jackmordaunt.dev@gmail.com>
This follows the convention where non-blocking operations are prefixed
with "try" to indicate as much.
Since select_raw in it's current form doesn't block, it should be
try_select_raw, and allow select_raw to name a blocking implementation.
This fixes a flaw in the original implementation: the returned index is
actually useless to the caller.
This is because the index returned refers to the internal "candidate"
list. This list is dynamic, and may not have all of the input channels
(if they weren't ready according to chan.can_{recv,send}). That means
the index is not guaranteed to mean anything to the caller.
The fix introduced here is to return the index into the input slice
(recvs,sends) and an enum to specify which input slice that is.
If no selection was made, then (-1, .None) is returned to communicate as
much.
Signed-off-by: Jack Mordaunt <jackmordaunt.dev@gmail.com>
1. store alignment instead of original pointer
2. implement .Query_Info
3. poison the header and alignment portion of the allocation
4. .Resize uses `max(orig_alignment, new_alignment)` as it's alignment
now
5. .Free passes along the original alignment
free on tlsf poisons the entire block, while alloc might only unpoison a
part of it (cause it's size is aligned up). This causes free to
potentially poison an already poisoned portion, which is a
use-after-poison.
Because this is "fine" and intended, I opted to just
@no_sanitize_address it.
Feoramund
PePerRoNii
Laytan Laats
Jack Mordaunt
Jeroen van Rijn