image: Undefined behavior detected by miri
I just discovered an UB whilst testing another project with miri. Primitive::from_slice
andPrimitive::from_slice_mut
perform an invalid unsafe cast, which is detected by miri.
EDIT: #1358 showed that it is just a matter of a wrong as_ptr
fn, therefore Primitive::from_slice
is likely to be unaffected.
Expected
cargo +nightly miri test
should not raise any problem.
Actual behaviour
test buffer_::test::mut_iter
triggers UB.
Reproduction steps
Just run miri on tests ☺️
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 16 (8 by maintainers)
No test failed with HEAD at e0261ce3b8b612650b2a24b8da22fc5410d23fa1 (but going back to 32bae1f463ed2197bc7c53be610cc179e15c387e reproduces the UB failure from the OP).
Sanitised log (the tests I skipped because they OOMed are marked accordingly):
Raw log here, just in case.
The truncation tests took over 12 hours to compile and OOMed immediately, so they remain unchecked.
If there’s anything else I can run miri on now or in future, I’m of course more than happy to.
I have a 96G amd64 machine, I’ll spin the tests there as well.
Good points on bytemuck being MIRI tested without issue. Then we can close this for now. That said, any additional small and quickly executed tests that cover some of the
unsafe
code would be appreciated, in any dependency as well 😃@lu-zero Thanks for the dedication. Due to your efforts, we say that
image
had a literal CPU-month dedicated to running them (960:43.10
). Feel free to stop at any point if you need your computer. If you can, comment with the log here so any one reading this later knows which tests were not covered yet.I can tell you that
codecs::png::tests::ensure_no_decoder_off_by_one
is probably showing a pathological case in miri.After 4h20 of CPU time (plus a single restart to add
-Zmiri-disable-isolation
40 minutes in :v), I’m at 43/137 tests with miri. I’d rather not restart this for reasons I assume obvious, and it’s currently at 52.5G resident set, so I can hardly run another set of tests in parallel (which miri is not doing for some reason, so those four hours are on one out of the twenty four CPUs, I’m pretty sure, which kinda sucks since they’re relatively slow).If there’s an easy way to find out which tests resolve to
unsafe
blocks, as you say, then I’ll be happy to restrict to those tests in future, but I don’t know of one nor particularly feel like going through over a hundred tests when I can just let’er rip overnight instead tbh.It also shouldn’t be strictly necessary to run all tests. Only those which eventually might call into
unsafe
code might yield interesting results in miri, apart from bugs in the compiler or standard library. I’m sure many tests are very verbose in this regard, in particular the reference image rendering test suite test a miniscule amount of unsafe code as many decoders are entirely safe.I did not try, but I am trying now to run all the tests with miri. 😉