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
rust-lang/rust#113113 fixed some bugs in ZST handling of the core collections. I wonder if there is a way that Miri could help find those bugs?
Unfortunately the Rust global allocator says that allocating ZST is UB, so when the collections use the global allocator then ZST allocations never reach Miri -- or put differently, there's not actually a bug with Vec<T, Global>. So I guess to detect this we'd have to explicitly use Vec<T, System>? Then we could make the Miri implementation of malloc actually create a new (zero-sized) allocation on malloc(0), and so failing to pass that to free would be a leak. Passing a dangling pointer to free is already UB (except if it is NULL) so we should also be able to detect that case.
However, currently I don't think that would help. System::alloc ends up here so we never end up even calling malloc(0). I guess we'd need our own allocator for this test that wraps malloc more directly?
rust-lang/rust#113113 was only concerned with the Allocator interface which, unlike GlobalAlloc, does allow allocating ZSTs. The problem was that ZSTs were being freed while not allocated and/or allocated and then leaked.
I don't think that it's Miri's job to catch this since this is library UB (the requirements of the Allocator trait are being violated). You would want some form of ZST-tracking allocator to verify this, somewhat like the one used in the tests of that PR.
rust-lang/rust#113113 fixed some bugs in ZST handling of the core collections. I wonder if there is a way that Miri could help find those bugs?
Unfortunately the Rust global allocator says that allocating ZST is UB, so when the collections use the global allocator then ZST allocations never reach Miri -- or put differently, there's not actually a bug with
Vec<T, Global>
. So I guess to detect this we'd have to explicitly useVec<T, System>
? Then we could make the Miri implementation of malloc actually create a new (zero-sized) allocation onmalloc(0)
, and so failing to pass that tofree
would be a leak. Passing a dangling pointer tofree
is already UB (except if it is NULL) so we should also be able to detect that case.However, currently I don't think that would help.
System::alloc
ends up here so we never end up even callingmalloc(0)
. I guess we'd need our own allocator for this test that wrapsmalloc
more directly?Cc @thomcc @Amanieu maybe you have some further ideas here.
The text was updated successfully, but these errors were encountered: