Change:
When running the Tokio test suite through CI using the beta/nightly compiler, the FreeBSD 32-bit build encounters a segmentation fault. After running CI with a few different configurations, I've found two different cases of the failure. The first segfault is in the test also encounters a segfault. Please see for more output from the CI runs. Both failures happen in tests that interact with the file system. There are other tests that pass and don't touch the file system (e.g. all unit tests in pass). As Tokio has no special logic for using the file system and just calls std, and as the test is not calling into any Tokio code at all, this looks an awful lot like a bug somewhere in std's filesystem handling code. But that is just a guess. I don't have access to a FreeBSD machine, so it is difficult for me to investigate further. The 64-bit FreeBSD build does not encounter these failures. There also are no problems when using the latest stable compiler. Note that the 32-bit binaries in question are cross-compiled from and executed on a 64-bit FreeBSD host machine. Failing toolchains: Passing toolchains:
I can try to bisect it to a specific nightly next week. If it's useful, you all are welcome to use our CI to debug this - you can open a PR to Tokio to run our CI setup.
it calls various tokio macros, doesn't it?? also, it doesn't seem to call anything in std besides , so i'm not sure how this could be a path handling bug?
Is this our compiler or is it the one from FreeBSD ports? They modded the target.
I have bisected the issue. It succeeds on nightly-2024-08-20 and fails on nightly-2024-08-21. The test calls into the  crate, which uses to probe which build tests exists. I got the compiler from rustup, so I assume it's your compiler. Our ci script runs the following commands: with normally set to , but under these tests I set it to or for testing other compilers. This is happening on a host.
Yep, that's our sigsegv, comrade!
Minimized: (any file that exists will do)
Bisection points to Which notes In particular: So... is it wrong to use a FreeBSD 12 ABI on a FreeBSD 14 system? Because that's what we're apparently trying to do here.
Hello there seems to be a bit of confusion afoot!
I've reproduced the problem locally, and I'll take a look.
I'm pretty sure that this is a bug in libc. While I work on a patch, could one of you toolchain experts please suggest to me how I might compile an arbitrary crate using a patched version of libc for std?
It should be sufficient to use in for , with presumably overriding to a or a repo. That will let you build a patched std, the new path should be reflected in the lock file.
Sorry but I need more help than that. I also need to know how to build, for example, Tokio using the patched std.
uhh honestly I would just build the entire stage 1 compiler with the patched std and then build tokio with that. I can look up the incantation for using the stage 0 std with an existing nightly if that would take forever, though.
Ah here we go, you want to do this: then should work?
that almost works. But I can't cross-compile from x86_64 to x86. Could you please tell what I must do to enable that? When I try, I get this:
you should be able to use to cross-compile the standard library.
I tried that, but the compiler thinks it's beta, not nightly, so it won't allow it. Is there a setting I can use to build it as a nightly compiler instead?
you can to allow using nightly features on a beta compiler (yes it's a hack, but it's probably fine for a quick repro)
also, is a beta compiler, if you want an actual nightly, you need to build stage1
With help from and I have a working patch in review at . HOWEVER, it only fixes on the libc-0.2 branch. I'll need to prepare a separate PR for the main branch. Also, I haven't tested on 32-bit architectures other than i386. I'm still trying to get access to some. Finally, I found some additional errors in other structures that require fixing. But they're all pretty obscure structures that the standard library doesn't use.
Oh, the way to do that without is to add this to the
Thank you for taking care of this!
WG-prioritization assigning priority (). label -I-prioritize +P-high
The relevant fixes have been merged into libc. So this bug will be fixed if libc makes a new release and rustc incorporates it.
libc has released. So if you update rust to use libc 0.2.160 or later this bug should be fixed.
As this bug has landed in a stable release, it is now causing CI failures in Tokio's CI setup. Please advise on what we should do. Will this get backported to 1.82, or should we freeze our FreeBSD CI to use 1.81.0?

Discussion:
# This file is automatically @generated by Cargo. # It is not intended for manual editing. <del> version = 3 </del> <ins> version = 4 </ins> [[package]] name = "addr2line"

[[package]] name = "libc" <del> version = "0.2.159" </del> <ins> version = "0.2.161" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "561d97a539a36e26a9a5fad1ea11a3039a67714694aaa379433e580854bc3dc5" </del> <ins> checksum = "8e9489c2807c139ffd9c1794f4af0ebe86a828db53ecdc7fea2111d0fed085d1" </ins> dependencies = [ "rustc-std-workspace-core", ]

addr2line = { version = "0.22.0", optional = true, default-features = false } [target.'cfg(not(all(windows, target_env = "msvc")))'.dependencies] <del> libc = { version = "0.2.159", default-features = false, features = [ </del> <ins> libc = { version = "0.2.161", default-features = false, features = [ </ins> 'rustc-dep-of-std', ], public = true }