fs::metadata() crashes on FreeBSD 12 due to layout change in stat.h

[lukaslueg]

The layout of struct stat used to be this in FreeBSD 11, in FreeBSD 12 it's now this. This causes the FreeBSD-specific implementation of std::fs::metadata() to crash for 1.18 and nightly as of 17/06/15, as it's stack frame get's boiled up.

Can be reproduced via

use std::fs;
fn main() {
    println!("{:?}", fs::metadata("Cargo.toml"));
}

Downstream this appeared in alacritty/alacritty#618

[semarie]

I would like to point a pre-RFC discussion about introducing a way in Rust to permit libc to represent differents layouts per OS version. I think there is need to move forward.

[alexcrichton]

We discussed this at libs triage today and the conclusion was that this is indeed bad! We would be fine in the very near future adding dynamic detection to do the right thing at runtime. In the long term we decided to see how @semarie's rfc plays out.

[johalun]

Is there a quick fix for this? This stops me from building a few (probably many) crates..

[johalun]

Here's a temporary fix for those who can't wait
https://github.com/johalun/rust-ino64
Just re-apply each time you update nightly with rustup.

[kirillrdy]

@johalun Thanks for a workaround ! 🍺

[dumbbell]

Hi!

I prepared a patch to support the two breaking changes in FreeBSD 12.x (see rust-lang/libc#721). I tested them successfully on FreeBSD 10.3 and FreeBSD 12.0, using the testsuites of mio and hyper.

However, I'm not sure my solution around struct kevent is correct and I would love to hear from others. The pull request gives all the details about the patch and what I had in mind.

[mattmacy]

@dumbbell there's an ongoing discussion about the fact that Rust has inadvertently baked in UBs on !Linux platforms by creating its own private copies of system headers, that are essentially an arbitrary version. rust-lang/libc#570 (comment)

Cargo needs to grow support for doing the equivalent of parsing uname -K and passing that as target_os_version.

For the time being I've accepted that when compiling I need to just append the following 3 lines to the Cargo.toml of any root crate when building on HEAD:

[patch.crates-io]
mio = { git = "https://github.com/FreeBSDRust/mio" }
libc = { git = "https://github.com/FreeBSDRust/rust-libc" }

[mattmacy]

Actually - although I managed to get jsonrpc_http_server bits to work yesterday by patching some of the dependent ports and then using [patch.crates-io] overrides, today I tried building netmap_sys with user libs which failed in the gcc crate, presumably because of something in libstd. I tried installing the FreeBSD port, but the cargo in that version wouldn't let me override libc (if that's something only available in nightlies you really need to make it standard) so although it compiled the binary didn't actually work. I've lost too much time on this to consider Rust a viable option for any near-term deadlines and have concluded that Rust really isn't cross-platform outside of tier 1 targets right now.

[valpackett]

Here's a fun thing. @johalun's amazing method of patching old_fstat.c into an already installed (rustup) std lib messes with…

Mesa OpenGL driver loading. Running glutin or webrender examples compiled with an unpatched compiler, my GPU driver loads fine. With a patched compiler:

libGL error: MESA-LOADER: failed to retrieve device information
[…] libGL error: failed to load driver: amdgpu
[…] libGL: OpenDriver: trying /usr/local/lib/dri/swrast_dri.so

And no, MESA_LOADER_DRIVER_OVERRIDE=radeonsi doesn't help — if it loads the right driver via manual override, that driver can't communicate to the GPU device either:

amdgpu: drmGetDevice2 failed.
do_winsys_init: DRM version is 3.8.0 but this driver is only compatible with 2.12.0 (kernel 3.2) or later.
libGL error: failed to create dri screen
libGL error: failed to load driver: radeonsi

The ports/pkg rustc, compiled normally with the same old_fstat changes patched in at the source level (UPD: used on the bootstrap compiler only; actual rust patch is used instead on the resulting build), does not have this problem. I guess I'll have to resurrect the lang/rust-nightly port…

[valpackett]

Here's a working nightly Rust toolchain for FreeBSD 12-CURRENT: rustc std cargo rls analysis docs. Don't ask me how I built it :D

(plus fully updated libc)

[bdrewery]

Technically this is not fixed yet as I need to update the submodule and the bootstrap needs to get the fix. Will be a few days.

[bdrewery]

The last piece for this should be updating the src/stage0.txt beta used. I am testing that now.