Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Rust 1.56 injected a valgrind incompatibility for Linux/AAarch64 #90316

Closed
pnkfelix opened this issue Oct 26, 2021 · 6 comments
Closed

Rust 1.56 injected a valgrind incompatibility for Linux/AAarch64 #90316

pnkfelix opened this issue Oct 26, 2021 · 6 comments
Labels
C-bug Category: This is a bug. P-high High priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@pnkfelix
Copy link
Member

pnkfelix commented Oct 26, 2021 •
edited
Loading

Code

I tried this code:

fn main() { let _n = std::time::Instant::now(); }

and ran it under valgrind.

I expected to see this happen: Successful program run with 0 errors from valgrind.

Instead, this happened:

$ valgrind ./target/debug/instant
==11772== Memcheck, a memory error detector
==11772== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==11772== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==11772== Command: ./target/debug/instant
==11772==
ARM64 front end: load_store
disInstr(arm64): unhandled instruction 0xC87F2D89
disInstr(arm64): 1100'1000 0111'1111 0010'1101 1000'1001
==11772== valgrind: Unrecognised instruction at address 0x11ffa4.
==11772==    at 0x11FFA4: atomic_umax<u128> (atomic.rs:2574)
==11772==    by 0x11FFA4: fetch_max (atomic.rs:1996)
==11772==    by 0x11FFA4: monotonize (monotonic.rs:91)
==11772==    by 0x11FFA4: monotonize (monotonic.rs:5)
==11772==    by 0x11FFA4: std::time::Instant::now (time.rs:270)
==11772==    by 0x10EB77: instant::main (main.rs:1)

Version it worked on

It most recently worked on: Rust 1.55

Version with regression

rustc --version --verbose:

rustc 1.56.0 (09c42c458 2021-10-18)
binary: rustc
commit-hash: 09c42c45858d5f3aedfa670698275303a3d19afa
commit-date: 2021-10-18
host: aarch64-unknown-linux-gnu
release: 1.56.0
LLVM version: 13.0.0

I also narrowed it down to which nightly injected the bug:

ubuntu@ip-172-31-93-250:~/instant$ cargo  nightly-2021-08-20 build
   Compiling instant v0.1.0 (/home/ubuntu/instant)
    Finished dev [unoptimized   debuginfo] target(s) in 0.66s
ubuntu@ip-172-31-93-250:~/instant$ valgrind ./target/debug/instant
==14475== Memcheck, a memory error detector
==14475== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==14475== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==14475== Command: ./target/debug/instant
==14475==
==14475==
==14475== HEAP SUMMARY:
==14475==     in use at exit: 0 bytes in 0 blocks
==14475==   total heap usage: 9 allocs, 9 frees, 1,977 bytes allocated
==14475==
==14475== All heap blocks were freed -- no leaks are possible
==14475==
==14475== For lists of detected and suppressed errors, rerun with: -s
==14475== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
ubuntu@ip-172-31-93-250:~/instant$ cargo  nightly-2021-08-21 build
   Compiling instant v0.1.0 (/home/ubuntu/instant)
    Finished dev [unoptimized   debuginfo] target(s) in 0.67s
ubuntu@ip-172-31-93-250:~/instant$ valgrind ./target/debug/instant
==14502== Memcheck, a memory error detector
==14502== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==14502== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==14502== Command: ./target/debug/instant
==14502==
ARM64 front end: load_store
disInstr(arm64): unhandled instruction 0xC87F2D89
disInstr(arm64): 1100'1000 0111'1111 0010'1101 1000'1001
==14502== valgrind: Unrecognised instruction at address 0x11f6a0.
==14502==    at 0x11F6A0: atomic_umax<u128> (atomic.rs:2574)
==14502==    by 0x11F6A0: fetch_max (atomic.rs:1996)
==14502==    by 0x11F6A0: monotonize (monotonic.rs:91)
==14502==    by 0x11F6A0: monotonize (monotonic.rs:5)
==14502==    by 0x11F6A0: std::time::Instant::now (time.rs:251)
==14502==    by 0x10E9F3: instant::main (main.rs:1)

which makes sense, because I believe this was injected by PR #83093

(The above transcript includes an invocation of valgrind, v 3.15.0, that is not the latest. But I did a build of 3.18 and reproduced the same bug there as well.)
@pnkfelix pnkfelix added C-bug Category: This is a bug. regression-untriaged Untriaged performance or correctness regression. labels Oct 26, 2021
@rustbot rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Oct 26, 2021
@pnkfelix pnkfelix added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. regression-from-stable-to-stable Performance or correctness regression from one stable version to another. and removed regression-untriaged Untriaged performance or correctness regression. labels Oct 26, 2021
@pnkfelix
Copy link
Member Author

pnkfelix commented Oct 26, 2021 •
edited
Loading

My current hypothesis is that this is a bug entirely on the valgrind side. I reached out to the valgrind developers, and they floated a few hypotheses. E.g. that we might not be doing sufficient CPU detection on our side before going down code paths with instructions that valgrind does not yet handle. But they also said that they were mystified that we were encountering this.

In the meantime, here is the corresponding bug that I filed on the valgrind side: https://bugs.kde.org/show_bug.cgi?id=444399

(I believe the valgrind developers will be investigating it more in the next few days.)

@apiraino
Copy link
Contributor

Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.

@rustbot label -I-prioritize P-high

@rustbot rustbot added P-high High priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Oct 27, 2021
@hkratz
Copy link
Contributor

hkratz commented Oct 28, 2021 •
edited
Loading

Just to simplify the code, as the original example does no longer reproduce for me on nightly.

This:

let _x = AtomicU128::new(3).fetch_max(7, Relaxed);

compiles with current nightly on aarch64-unknown-linux-gnu to:

atomictest::main:
 sub     sp, sp, #16
 mov     w9, #3
 mov     x8, sp
 stp     x9, xzr, [sp]
 mov     w9, #7
.LBB5_1:
 ldxp    x10, x11, [x8]
 cmp     x10, #7
 cset    w12, hi
 cmp     x11, #0
 cset    w13, ne
 csel    w12, w12, w13, eq
 cmp     w12, #0
 csel    x11, x11, xzr, ne
 csel    x10, x10, x9, ne
 stxp    w12, x10, x11, [x8]
 cbnz    w12, .LBB5_1
 add     sp, sp, #16
 ret

Valgrind complains about opcode 1100'1000 0111'1111 0010'1101 1000'1001, which is ldxp (see ARM reference maual page C6-1199). AFAICS ldxp is part of the normal ARMv8.0 instruction set, no target features required.

@hkratz
Copy link
Contributor

hkratz commented Oct 28, 2021 •
edited
Loading

Added a C reproducer to the valgrind bug report: https://bugs.kde.org/show_bug.cgi?id=444399#c3

@hkratz
Copy link
Contributor

hkratz commented Nov 5, 2021

Should this be closed now that it has been acknowledged to be a shortcoming of valgrind: https://bugs.kde.org/show_bug.cgi?id=444399#c5?

@pnkfelix
Copy link
Member Author

Closing as assumed fixed with https://sourceware.org/git/?p=valgrind.git;a=commit;h=530df882b8f60ecacaf2b9b8a719f7ea1c1d1650

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-bug Category: This is a bug. P-high High priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@pnkfelix @hkratz @apiraino @rustbot