`PartialEq` impl for `IpAddr` causes `SIGBUS` on `mips-unknown-linux-gnu`

[djkoloski]

I tried this code on mips-unknown-linux-gnu through cargo-cross:

use std::net::{IpAddr, Ipv4Addr};

fn main() {
    let value = IpAddr::V4(Ipv4Addr::new(31, 41, 59, 26));
    assert_eq!(&value, &value);
}

cross run --target mips-unknown-linux-gnu --verbose

I expected to see this happen: the program exits successfully.

Instead, this happened: qemu: uncaught target signal 10 (Bus error) - core dumped

This is truly baffling because:

1. This is extremely plain code, just a struct in an enum.
2. This is crashing in the implementation of PartialEq which has been generated by a derive.
3. Removing the outer IpAddr does not cause a crash.
4. Far more complex code runs successfully.

If this is a problem with cargo-cross instead, I would be happy to move the bug to the corresponding repo.

Meta

rustc --version --verbose:

rustc 1.64.0 (a55dd71d5 2022-09-19)
binary: rustc
commit-hash: a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52
commit-date: 2022-09-19
host: x86_64-pc-windows-msvc
release: 1.64.0
LLVM version: 14.0.6

[saethlin]

Trying to repro, but I can't.

╭ ➜ ben@archlinux:/tmp/scratch
╰ ➤ cross run --target mips-unknown-linux-gnu --verbose
+ cargo metadata --format-version 1 --filter-platform mips-unknown-linux-gnu
+ rustc --print sysroot
+ rustup toolchain list
+ rustup target list --toolchain stable-x86_64-unknown-linux-gnu
+ rustup component list --toolchain stable-x86_64-unknown-linux-gnu
+ /usr/bin/docker
+ /usr/bin/docker run --userns host -e 'PKG_CONFIG_ALLOW_CROSS=1' -e 'XARGO_HOME=/xargo' -e 'CARGO_HOME=/cargo' -e 'CARGO_TARGET_DIR=/target' -e 'CROSS_RUNNER=' -e TERM -e 'USER=ben' --rm --user 1000:1000 -v /home/ben/.xargo:/xargo:Z -v /home/ben/.cargo:/cargo:Z -v /cargo/bin -v /tmp/scratch:/project:Z -v /home/ben/.rustup/toolchains/stable-x86_64-unknown-linux-gnu:/rust:Z,ro -v /tmp/scratch/target:/target:Z -w /project -i -t ghcr.io/cross-rs/mips-unknown-linux-gnu:0.2.4 sh -c 'PATH=$PATH:/rust/bin cargo run --target mips-unknown-linux-gnu --verbose'
   Compiling scratch v0.1.0 (/project)
     Running `rustc --crate-name scratch --edition=2021 src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C metadata=415e3bf8bc61106d -C extra-filename=-415e3bf8bc61106d --out-dir /target/mips-unknown-linux-gnu/debug/deps --target mips-unknown-linux-gnu -C linker=mips-linux-gnu-gcc -C incremental=/target/mips-unknown-linux-gnu/debug/incremental -L dependency=/target/mips-unknown-linux-gnu/debug/deps -L dependency=/target/debug/deps`
    Finished dev [unoptimized + debuginfo] target(s) in 0.36s
     Running `/linux-runner mips /target/mips-unknown-linux-gnu/debug/scratch`
╭ ➜ ben@archlinux:/tmp/scratch
╰ ➤ echo $?
0

Is it possible this is related to a qemu version?

[djkoloski]

Maybe? I thought it might also be host platform specific but then remembered that the same issue occurred locally (on Windows) and in a GitHub action (on Ubuntu). I updated cross just in case as well and it still expressed for me.

[zachs18]

The github action you linked installs cross with cargo install cross --git https://github.com/cross-rs/cross.

I do see the issue when running with cross from --git, but not from crates.io, so maybe this is something that has changed between 2.4.0 on crates.io and HEAD of cross-rs. Or perhaps more likely, something that changed with the cross's dockerfile and how it calls qemu?

Here's another example program (intentionally performing an unaligned read of a u32)

unsafe fn read_u32_unaligned(ptr: *const [u8]) -> u32 {
    *ptr.cast()
}

fn main() {
    let x: Box<[u8; 8]> = Box::new([1,2,3,4,5,6,7,8]);

    unsafe {
        println!("{:08X}", read_u32_unaligned(&*x));
        println!("{:08X}", read_u32_unaligned(&x[1..])); // at least one of these accesses is definitely unaligned
    }
}

Gives these results:

Does not give SIGBUS on latest crates.io release of cross:

$ cargo install cross
...
$ cross run --target mips-unknown-linux-gnu
...
01020304
02030405

Gives SIGBUS on HEAD of cross:

$ cargo install cross --git https://github.com/cross-rs/cross
...
$ cross run --target mips-unknown-linux-gnu
...
01020304
qemu: uncaught target signal 10 (Bus error) - core dumped
Bus error (core dumped)

---

Maybe we should look into if the original example program is miscompiled down to something with an unaligned memory access? I looked at it a bit, but I do not know MIPS assembly enough to make sense of it.

[Noratrieb]

Between 2.4.0 and main of cross, QEMU has been bumped from 5.1.0 to 6.1.0.

[djkoloski]

Thanks for the help everyone, I think this is pretty conclusively a cross issue. I've moved the issue to the cross repo here: cross-rs/cross#1060

[zachs18]

I think this may be a QEMU issue or a miscompilation, and not a cross issue, since I can observe it without cross at all on qemu-mips version 7.0.0 (Debian 1:7.0+dfsg-7ubuntu2) on Ubuntu Kinetic (22.10 pre-release) using rust 1.64.0 stable.

# .cargo/config.coml
[target.mips-unknown-linux-gnu]
linker = "mips-linux-gnu-gcc"
runner = ["qemu-mips", "-L", "/usr/mips-linux-gnu", "-g", "23456"]

(same main.rs as OP, default Cargo.toml, run sudo apt install gcc-mips-linux-gnu qemu-user gdb-multiarch)

# Note: this will wait for GDB to connect
$ cargo run --target mips-unknown-linux-gnu
   Compiling rust-102722 v0.1.0 (/root/rust-102722-mwe)
    Finished dev [unoptimized + debuginfo] target(s) in 0.16s
     Running `qemu-mips -L /usr/mips-linux-gnu -g 23456 target/mips-unknown-linux-gnu/debug/rust-102722`
qemu: uncaught target signal 10 (Bus error) - core dumped
Bus error (core dumped)

# In another terminal
$ gdb-multiarch target/mips-unknown-linux-gnu/debug/rust-102722
gdb> sysroot /usr/mips-linux-gnu
gdb> target remote localhost:23456
gdb> c
Program received signal SIGBUS, Bus error.
...

Specifically, I observed that core::array::equality::{impl#9}::spec_eq<u8, u8, 4> (<T as core::array::equality::SpecArrayEq<U,_>>::spec_eq::hd4c38287a2b6c14f) was using lw (load word) with an unaligned address, which caused a SIGBUS.

The program is about to perform lw at,0(at) (basically at = *(at + 0);), but at is not word-aligned (0x3ffff049), so this causes a SIGBUS.

GDB Screenshots under QEMU 7.0.0

QEMU 7.0.0: GDB before lw at,0(at):

QEMU 7.0.0: GDB after lw at,0(at):

Note that this same instruction executes without SIGBUS on QEMU 6.2.0 for some reason.

GDB Screenshots under QEMU 6.2.0

QEMU 6.2.0: GDB before lw at,0(at):

QEMU 6.2.0: GDB after lw at,0(at):

---

Does anyone know for sure if MIPS allows unaligned accesses or not? If it does, then this may be a QEMU issue. If not, then this may be a miscompilation.

[djkoloski]

Reopening this since it seems worth investigating as a potential miscompilation. Thanks @zachs18 for putting in a ton of legwork to gather some more information!

[urosbericsyrmia]

I have run the code with both cargo and cross and it works fine. Are you sure the issue is still occurring?
Same main.rs as OP's, default Cargo.toml, config.toml is as follows:

[target.mips-unknown-linux-gnu]
linker = "mips-linux-gnu-gcc"
runner = ["qemu-mips", "-L", "/usr/mips-linux-gnu"]

After running cargo run -Z build-std --target mips-unknown-linux-gnu it finished successfully. Same thing with cross run -Z build-std --target mips-unknown-linux-gnu.
Can someone please confirm that this is also working for you?

[zachs18]

@urosbericsyrmia What version of QEMU are you using?

I can still reproduce this on QEMU 8.0.4 (in an Ubuntu 23.10 docker container) with a slightly modified fn main

use std::net::{IpAddr, Ipv4Addr};

fn main() {
    println!("A");
    let value = IpAddr::V4(Ipv4Addr::new(31, 41, 59, 26));
    assert_eq!(&value, &value);
    println!("B");
}

gives

cargo run -Z build-std --target mips-unknown-linux-gnu
   Compiling rust-102722 v0.1.0 (/rust-102722-mwe)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.49s
     Running `qemu-mips -L /usr/mips-linux-gnu target/mips-unknown-linux-gnu/debug/rust-102722`
A
Bus error (core dumped)

# rustc --version -v
rustc 1.78.0-nightly (a165f1f65 2024-03-12)
binary: rustc
commit-hash: a165f1f65015b1bd4afd2ec50700aaacf2e0c485
commit-date: 2024-03-12
host: x86_64-unknown-linux-gnu
release: 1.78.0-nightly
LLVM version: 18.1.0

# qemu-mips --version
qemu-mips version 8.0.4 (Debian 1:8.0.4+dfsg-1ubuntu3.23.10.3)
Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers

Now the first bus error happens is in _ZN4core3num23_$LT$impl$u20$usize$GT$9repeat_u817hde665bc3cd149eabE, a.k.a core::num::<impl usize>::repeat_u8::hde665bc3cd149eab, which calls usize::from_ne_bytes, which uses a transmute, which should not have alignment issues, so maybe this is a miscompilation? Or as said before, if MIPS-linux-gnu is supposed to allow unaligned reads, then this could be a QEMU issue.