unexpected panic while compiling firefox on arm64 #49281
Labels
C-bug
Category: This is a bug.
O-Arm
Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state
T-libs-api
Relevant to the library API team, which will review and decide on the PR/issue.
Comments
I sometimes get messages like this on s390x too, and usually it will pass if I try again. I haven't looked into it, but if this code insists on monotonicity, it may need to use a different clock source. |
cuviper
added
T-libs-api
sanxiyn
added
the
O-Arm
This was referenced Dec 18, 2018
Closed
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Jan 7, 2019
This commit is an attempt to force `Instant::now` to be monotonic through any means possible. We tried relying on OS/hardware/clock implementations, but those seem buggy enough that we can't rely on them in practice. This commit implements the same hammer Firefox recently implemented (noted in rust-lang#56612) which is to just keep whatever the lastest `Instant::now()` return value was in memory, returning that instead of the OS looks like it's moving backwards. Closes rust-lang#48514 Closes rust-lang#49281 cc rust-lang#51648 cc rust-lang#56560 Closes rust-lang#56612 Closes rust-lang#56940
bors
added a commit
that referenced
this issue
Jan 8, 2019
std: Force `Instant::now()` to be monotonic This commit is an attempt to force `Instant::now` to be monotonic through any means possible. We tried relying on OS/hardware/clock implementations, but those seem buggy enough that we can't rely on them in practice. This commit implements the same hammer Firefox recently implemented (noted in #56612) which is to just keep whatever the lastest `Instant::now()` return value was in memory, returning that instead of the OS looks like it's moving backwards. Closes #48514 Closes #49281 cc #51648 cc #56560 Closes #56612 Closes #56940
bors
added a commit
that referenced
this issue
Jan 8, 2019
std: Force `Instant::now()` to be monotonic This commit is an attempt to force `Instant::now` to be monotonic through any means possible. We tried relying on OS/hardware/clock implementations, but those seem buggy enough that we can't rely on them in practice. This commit implements the same hammer Firefox recently implemented (noted in #56612) which is to just keep whatever the lastest `Instant::now()` return value was in memory, returning that instead of the OS looks like it's moving backwards. Closes #48514 Closes #49281 cc #51648 cc #56560 Closes #56612 Closes #56940
AGSaidi
added a commit
to AGSaidi/rust
that referenced
this issue
Sep 4, 2021
While issues have been seen on arm64 platforms the Arm architecture requires that the counter monotonically increases and that it must provide a uniform view of system time (e.g. it must not be possible for a core to receive a message from another core with a time stamp and observe time going backwards (ARM DDI 0487G.b D11.1.2). While there have been a few 64bit SoCs that have bugs (rust-lang#49281, rust-lang#56940) which cause time to not monotonically increase, these have been fixed in the Linux kernel and we shouldn't penalize all Arm SoCs for those who refuse to update their kernels: SUN50I_ERRATUM_UNKNOWN1 - Allwinner A64 / Pine A64 - fixed in 5.1 FSL_ERRATUM_A008585 - Freescale LS2080A/LS1043A - fixed in 4.10 HISILICON_ERRATUM_161010101 - Hisilicon 1610 - fixed in 4.11 ARM64_ERRATUM_858921 - Cortex A73 - fixed in 4.12 255a3f3 std: Force `Instant::now()` to be monotonic added a mutex to work around this problem and a small test program using glommio shows the majority of time spent acquiring and releasing this Mutex. 3914a7b tries to improve this, but actually makes it worse on big systems as for 128b atomics a ldxp/stxp pair (and successful loop) is required which is expensive as a lock and because of how the load/store-exclusives scale on large Arm systems is both unfair to threads and tends to go backwards in performance.
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this issue
Oct 16, 2021
…ually-monotonic, r=yaahc linux/aarch64 Now() should be actually_monotonic() While issues have been seen on arm64 platforms the Arm architecture requires that the counter monotonically increases and that it must provide a uniform view of system time (e.g. it must not be possible for a core to receive a message from another core with a time stamp and observe time going backwards (ARM DDI 0487G.b D11.1.2). While there have been a few 64bit SoCs that have bugs (rust-lang#49281, rust-lang#56940) which cause time to not monotonically increase, these have been fixed in the Linux kernel and we shouldn't penalize all Arm SoCs for those who refuse to update their kernels: SUN50I_ERRATUM_UNKNOWN1 - Allwinner A64 / Pine A64 - fixed in 5.1 FSL_ERRATUM_A008585 - Freescale LS2080A/LS1043A - fixed in 4.10 HISILICON_ERRATUM_161010101 - Hisilicon 1610 - fixed in 4.11 ARM64_ERRATUM_858921 - Cortex A73 - fixed in 4.12 255a3f3 std: Force `Instant::now()` to be monotonic added a Mutex to work around this problem and a small test program using glommio shows the majority of time spent acquiring and releasing this Mutex. 3914a7b tries to improve this, but actually makes it worse on big systems as for 128b atomics a ldxp/stxp pair (and successful loop) for v8.4 systems that don't support FEAT_LSE2 is required which is expensive as a lock and because of how the load/store-exclusives scale on large Arm systems is both unfair to threads and tends to go backwards in performance. A small sample program using glommio improves by 70x on a 32 core Graviton2 system with this change.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Oct 17, 2021
…lly-monotonic, r=yaahc linux/aarch64 Now() should be actually_monotonic() While issues have been seen on arm64 platforms the Arm architecture requires that the counter monotonically increases and that it must provide a uniform view of system time (e.g. it must not be possible for a core to receive a message from another core with a time stamp and observe time going backwards (ARM DDI 0487G.b D11.1.2). While there have been a few 64bit SoCs that have bugs (rust-lang#49281, rust-lang#56940) which cause time to not monotonically increase, these have been fixed in the Linux kernel and we shouldn't penalize all Arm SoCs for those who refuse to update their kernels: SUN50I_ERRATUM_UNKNOWN1 - Allwinner A64 / Pine A64 - fixed in 5.1 FSL_ERRATUM_A008585 - Freescale LS2080A/LS1043A - fixed in 4.10 HISILICON_ERRATUM_161010101 - Hisilicon 1610 - fixed in 4.11 ARM64_ERRATUM_858921 - Cortex A73 - fixed in 4.12 255a3f3 std: Force `Instant::now()` to be monotonic added a Mutex to work around this problem and a small test program using glommio shows the majority of time spent acquiring and releasing this Mutex. 3914a7b tries to improve this, but actually makes it worse on big systems as for 128b atomics a ldxp/stxp pair (and successful loop) for v8.4 systems that don't support FEAT_LSE2 is required which is expensive as a lock and because of how the load/store-exclusives scale on large Arm systems is both unfair to threads and tends to go backwards in performance. A small sample program using glommio improves by 70x on a 32 core Graviton2 system with this change.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi, I see this strange error while trying to compile firefox-59.0.1 with rust-1.23 on arm64 laptop running gentoo linux. It says, my bug report would be appreciated. I'd also appreciate any feedback.
I would be happy to provide any additional information.
The text was updated successfully, but these errors were encountered: