rebis-dev: Fix Heap::compute_pstr_size being off by one cell #2759
Conversation
This one was a toughie: it turns out that using `ptr::align_of()`` was a bad idea, since the buffer in `Heap` itself is not aligned to `Heap::heap_cell_alignment()`, so `ptr::align_of()` would sometimes return lower values than expected. That made for an heisenbug: if the alignment of the heap happened to be 4, then the bug wouldn't trigger.
rebis-dev: Fix imports for benches
rebis-dev: Fix UB detected by miri in tests
|
It turns out that I had missed one instance of the issue spotted in #2729: I've rewritten it (and renamed it to the more accurate To make it easy to use it in the implementations of |
- Fix Heap::compute_pstr_size being off at len=0, len=n*align and null bytes (compute_pstr_size now more accurately reflects the behavior of allocate_pstr). - Add debug assertion for the behaviour of compute_pstr_size - Fix off-by-one errors in build_functor
…t to deduplicate unsafe code scan_slice_to_str was close to being safe already, but the code using it needed to be unsafe, and the safety of scan_slice_to_str was hinging on the correctness of the caller unsafe block. It also wrongly assumed that Heap.inner.ptr was aligned to Heap::heap_cell_alignment(). Instead, I have rewritten `scan_slice_to_str` (and renamed it to the more accurate name `scan_pstr_at`), to fix the incorrect computation caused by this wrong assumption, and to reduce the unsafe blocks to their minimum, whose safety I could then prove. The invariants of Heap remain to be fully vetted, as some of the code in this module remain ~wildly unsafe~ :)
adri326
force-pushed
the
fix-compute_pstr_size
branch
from
8c856bd to
5e08d4d
Compare
adri326
changed the title
|
A few CI tests apparently fail, I hope at least the formatting would be easy to resolve. |
|
The formatting issue is omnipresent on rebis-dev, running |
So it looks like my fix for segfault around heap and PStr had an off-by-one error in the logic for
compute_pstr_size, which this PR fixes.This off-by-one error was compounded by a second off-by-one error within the logic of
build_functor!()(some parts did not account for the[]atom appended toPStrs), which happened to cancel out with the previous, invalid implementation ofcompute_pstr_size.This does not address #2757 (and I would prefer to fix that issue in a separate PR, so that we can get the unit tests of
rebis-devback in order), though the logic forcompute_pstr_sizeshould coincide with the corrected behavior of #2757. The test cases I've added here ought to be tweaked once the correct behavior is set in stone.Now
Heap::compute_pstr_sizeaccurately measures the number of bytes needed byHeap::allocate_pstr(except in the instances of #2757).I've also simplified the logic a bit, and cleaned up the affected tests of
build_functor:)