Undefined behavior when encoding AVIF image #2108
Comments
|
Seems that miri thinks the loop9::Triple::new(1u8, 2, 3).as_ref();Produces: However, there doesn't seem to be a git repository linked from the crate page to create an issue against. @kornelski, since you're listed as the crate owner, could you take a look? |
|
I've updated the crate. It didn't like me using address of the first field as the address of the struct. So I don't think there's any actual problem there, since the two pointers are numerically the same, it takes miri to spot the difference. |
|
I updated the repository reproducing this issue to use OutputThis error doesn't happen with Output
|
|
Given that crossbeam is quite widely used, I'd speculate that the undefined behavior that's causing the illegal instruction is coming from elsewhere. Any chance you'd be able to capture a backtrace, perhaps by running in GDB? You also may be able to run rav1e directly and see if you still get the crash |
|
I do recommend trying rav1e relies on raw assembly internally so I don't think miri will be much help here since it doesn't support that. Address Sanitizer will fare better but it won't be able to instrument the assembly code either. Perhaps |
|
Running miri with |
|
Ah, Let's copy their flags and see if Thanks to @saethlin for discovering this! |
|
Based on their comments, |
|
The original error is "illegal hardware instruction". How likely is it that some of the assembly just... contains an instruction that your CPU doesn't support? |
|
On an M1 - not likely. The only thing I can think of that wouldn't be supported is SVE, and I doubt |
makes it distinctly unlikely that this is related to using an unavailable CPU feature. |
|
I've managed to reproduce this issue using just the Output |
|
Great! That narrows things down a lot. It's best to report it to the rav1e issue tracker: https://github.com/xiph/rav1e/issues |
|
That diagnostic is just identifying the Miri has an alternative aliasing model which fixes that issue, you can swap to it with But in either case, I think that reducing an example that will SIGILL would also be very educational. There's an unexpected optimization happening, and reducing the unexpectly-optimized code would help point out whether this is UB or a miscompilation. |
|
I redid the work at https://github.com/astral4/avif-ub to isolate error signals like SIGILL instead of Miri complaints. Running in release mode with |
|
I'm looking at commit Perhaps there's some global Cargo setting you've set that is required to expose the issue? Can you |
|
Mine looks like this: |
|
I don't see any extra flags in there. I tried this on the M1 I have access to and I can't provoke a crash there either. I believe you that there's a problem here, but I don't know how to work on this without the ability to reproduce it. If you can build a |
|
I give up on trying to reproduce this issue. My goal was to build a Docker image containing a Rust toolchain that could compile to the First, I tried using OutputI was stuck because I had no idea how to address this, so I looked for another approach. Next, I tried using a pre-built image from this repository. I was able to successfully compile the program, but I didn't observe SIGILL/SIGSEGV. Then, I tried to reproduce the issue using OutputAt this point, I'm not sure what I can do. The problem still exists, obviously, but all of the possible causes mentioned so far have been dismissed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This happens with version 0.24.8. I am using a M1 MacBook Pro with
rustc 1.75.0 (82e1608df 2023-12-21).Running the program that brings up this issue results in
zsh: illegal hardware instruction.Miri output
The output of
cargo +nightly miri run(usingrustc 1.77.0-nightly (2319be8e2 2024-01-12)) is:Reproduction steps
cargo run --releaseI only observed UB on release builds with
panic = "abort"andlto = true, but Miri still reports UB otherwise.The text was updated successfully, but these errors were encountered: