-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UB in Default impl of GenericArray #97
Comments
Ouch. Okay, I'll prioritize fixing these UB issues tomorrow. |
Just added a comment:
Note that we could eventually make use of the https://crates.io/crates/array_init crate since its purpose is to initialize arrays which effectively is happening in this routine. I have also implicitely tested the I have also tried to run |
Would you try adding the latest master branch to your project to double check that the current changes fix your issue? Running miri on Replace: |
I can confirm using your branch I no longer see the undefined behaviour via |
Should be fixed in 0.14.0. Please reopen if the issue persists. |
I'll note that on Rust 1.48.0 on embedded arm systems, specifically ARM thumbv7em-none-eabihf, |
Today I was running
cargo miri test
on one of my projects that is using thegeneric-array
crate internally. Thecargo miri test
runs tests of the project using the Rust MIR interpretermiri
. Due to execution the tool is sometimes able to detect undefined behaviour in Rust code upon execution - however, there might be false positives.The output of
miri
's execution:So it seems to be a problem with uninitialized data in the
Default
implementation ofGenericArray
where it is using aManuallyDrop
with uninitialized data.This is the test code that triggered the UB of my crate that is using
generic-array
:https://github.com/paritytech/ink/blob/redo-init-and-flush/core/src/storage2/collections/smallvec/tests.rs#L60
I belive the problem is somewhere in this method:
https://github.com/fizyk20/generic-array/blob/master/src/lib.rs#L207
The
array
field is of typeMaybeUninit
and during the loop infn generate
(same file) the underlying array is initialized. However, in the linked method no call toassume_init
is made and instead acore::mem::ptr::read
is performed on the potentially uninitializedarray
contents. This doesn't necessarily need to be wrong, however, it could be that it confusesmiri
.The text was updated successfully, but these errors were encountered: