1.71 broken std::time on musleabi on old kernels

[vi]

Can't run Rust programs that use std::time build with 1.71+ for static arm-unknown-linux-musleabi on a synology_armada38x_ds218j NAS box running Linux 3.10.105.

Code

fn main() {
    println!("{:?}", std::time::Instant::now());
}

I expected to see this happen:

Instant { tv_sec: 3980925, tv_nsec: 99749932 }

Instead, this happened:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 22, kind: InvalidInput, message: "Invalid argument" }', library/std/src/sys/unix/time.rs:418:72
stack backtrace:
   0: rust_begin_unwind
             at /rustc/eb26296b556cef10fb713a38f3d16b9886080f26/library/std/src/panicking.rs:593:5
   1: core::panicking::panic_fmt
             at /rustc/eb26296b556cef10fb713a38f3d16b9886080f26/library/core/src/panicking.rs:67:14
   2: core::result::unwrap_failed
             at /rustc/eb26296b556cef10fb713a38f3d16b9886080f26/library/core/src/result.rs:1651:5
   3: core::result::Result<T,E>::unwrap
             at /rustc/eb26296b556cef10fb713a38f3d16b9886080f26/library/core/src/result.rs:1076:23
   4: std::sys::unix::time::inner::<impl std::sys::unix::time::Timespec>::now
             at /rustc/eb26296b556cef10fb713a38f3d16b9886080f26/library/std/src/sys/unix/time.rs:418:13
   5: qqq::main
             at /tmp/shell-bash.1R152YwY/qqq/src/main.rs:2:22

Version it worked on

For example, 1.70

strace is short:

2100  clock_gettime(CLOCK_MONOTONIC, {3982598, 189908570}) = 0
2100  write(1, "Instant { tv_sec: 3982598, tv_ns"..., 48) = 48

Version with regression

For example, 1.71.1:

2198  syscall_403(0x1, 0x7e830b48, 0x1, 0, 0x7e830b78, 0x75134) = -1 (errno 22)
2198  write(2, "thread '", 8)           = 8
2198  write(2, "main", 4)               = 4
2198  write(2, "' panicked at '", 15)   = 15

or, for example, recent 1.82.0:

backtrace

``` thread 'main' panicked at std/src/sys/pal/unix/time.rs:130:68: called `Result::unwrap()` on an `Err` value: Os { code: 22, kind: InvalidInput, message: "Invalid argument" } stack backtrace: 0: rust_begin_unwind at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/panicking.rs:662:5 1: core::panicking::panic_fmt at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/panicking.rs:74:14 2: core::result::unwrap_failed at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/result.rs:1677:5 3: core::result::Result::unwrap at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/result.rs:1102:23 4: std::sys::pal::unix::time::Timespec::now at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/sys/pal/unix/time.rs:130:9 5: qqq::main at /tmp/shell-bash.1R152YwY/qqq/src/main.rs:2:22 6: core::ops::function::FnOnce::call_once at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/ops/function.rs:250:5 note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. ``` Revelant strace snippet is similar.

I suspect is is related to Musl library update in 1.71.

@rustbot modify labels: +regression-from-stable-to-stable -regression-untriaged

[workingjubilee]

@vi Is a more recent version of Linux functional?

[vi]

I am slightly hesitant to update to it remotely, if it does not come back online it would be tricky to set it up again.

Other (non-Rust) musl-based programs also seem to have problems with time there.

[vi]

Related: #115921.

Hacking musl source code to avoid 64-bit time functions in clock_gettime worked around the issue in another (non-Rust) program.

[workingjubilee]

I am slightly hesitant to update to it remotely, if it does not come back online it would be tricky to set it up again.

Understandable, I only asked in the event it was relatively easy to set and reset.

[workingjubilee]

@vi Can you update the Rust application remotely with relative ease?

I am also curious to know if this is resolved by using -Ctarget-feature=-crt-static for the build.

[vi]

How will it run without musl dynamic libraries around?

Or does Rust distribution conveniently ships relevant *.so files to make non-static builds portable-ish (e.g. with ./ld.so --library-path trick)?

[workingjubilee]

Oh. Well, it wouldn't. I wasn't sure whether the Linux distro in question supplied any such runtime libraries, really.

[richfelker]

Cross post from #115921:

This is the infamous broken Synology kernel. Synology hijacked syscall numbers that were unassigned at the time to use for their own hacks to implement MSDOS fs emulation operations. Systems honoring the Linux ABI are unaffected; only the broken Synology kernels are affected. The only solution is to install seccomp filters to block the hijacked syscall range (make them all return -ENOSYS) so that fallback to time32 syscalls will happen.

[workingjubilee]

Right, that confirms this is a complete duplicate of that other issue then.

There is more debugging / hotfix-related advice (use at your own discretion) in that issue.

Thank you, @richfelker!