Skip to content

Running sanitizer tests fails with mixed ABI errors #147394

Open

Description

@djc

I tried this code:

RUSTFLAGS="-Z sanitizer=address -Cunsafe-allow-abi-mismatch=sanitizer" cargo +nightly -Z build-std test --target x86_64-unknown-linux-gnu --all-features

I expected to see this happen: tests pass/fail

Instead, this happened:

error: mixing `-Zsanitizer` will cause an ABI mismatch in crate `hashlink`
  |
  = help: the `-Zsanitizer` flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely
  = note: unset `-Zsanitizer` in this crate is incompatible with `-Zsanitizer=memory` in dependency `core`
  = help: set `-Zsanitizer=memory` in this crate or unset `-Zsanitizer` in `core`
  = help: if you are sure this will not cause problems, you may use `-Cunsafe-allow-abi-mismatch=sanitizer` to silence this error

Note that I already added the suppression option, but it doesn't seem to take effect here?

Meta

rustc --version --verbose:

rustc 1.92.0-nightly (839222065 2025-10-05)

(See CI: https://app.circleci.com/pipelines/github/djc/hashlink/189/workflows/58588dc4-d323-428f-a309-d950c5fa2b0f/jobs/180.)

Activity

  1. added
    C-bugCategory: This is a bug.
    on Oct 6, 2025
  2. added
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Oct 6, 2025
  3. djc commented on Oct 6, 2025

    @djc
    ContributorAuthor

    I cannot reproduce this on my own ARM64 Linux server. This just works:

    RUSTFLAGS="-Z sanitizer=address" cargo +nightly -Z build-std test --all-features
    

    (I also tried the CI without --target, and that still fails the same way as before.)

  4. added
    A-sanitizersArea: Sanitizers for correctness and code quality
    -Zbuild-stdUnstable cargo option: -Zbuild-std
    requires-nightlyThis issue requires a nightly compiler in some way. When possible, use a F-* label instead.
    on Oct 9, 2025
  5. saethlin commented on Oct 14, 2025

    @saethlin
    Member

    You're trying to use sanitizer=address but getting an error about sanitizer=memory? That's a transcription error or something is deeply wrong with your build environment.

  6. djc commented on Oct 14, 2025

    @djc
    ContributorAuthor

    @saethlin thanks for having a look! If you look at the original CI run, it seems to be similar:

    https://app.circleci.com/pipelines/github/djc/hashlink/189/workflows/58588dc4-d323-428f-a309-d950c5fa2b0f/jobs/180

    Maybe it doesn't rebuild dependencies correctly, so that an earlier sanitizer=address build is reused when I run with sanitizer=memory later?

  7. saethlin commented on Oct 14, 2025

    @saethlin
    Member

    Yeah, that's what it seems like to me. You should be able to pass --verbose to Cargo to see the exact flags being used. I usually also add -j1 so the output arrives in a simpler order. At least if you can see all the flags for the ASan build that should indicate if MSan crates are being pulled in from another build... Somehow.

  8. saethlin commented on Oct 14, 2025

    @saethlin
    Member

    I can repro locally. The fact that this only happens with doctests seems relevant.

  9. saethlin commented on Oct 14, 2025

    @saethlin
    Member

    Repros with an empty library crate. What in tarnation...

  10. saethlin commented on Oct 14, 2025

    @saethlin
    Member

    This bisects to #138736 but I think that PR just uncovered the problem

  11. saethlin commented on Oct 14, 2025

    @saethlin
    Member

    To repro, on an empty library crate run

    RUSTFLAGS="-Z sanitizer=memory" cargo test -Z build-std --target=x86_64-unknown-linux-gnu
    

    The trick is this note in the PR:

    For now, we should mark all sanitizers as target modifiers except for these: AddressSanitizer, LeakSanitizer

    And this diagnostic:

    = note: unset `-Zsanitizer` in this crate is incompatible with `-Zsanitizer=memory` in dependency `std`
    

    The problem is that to set compiler flags in doctests you need to set RUSTDOCFLAGS. This is a pretty classic footgun, and a number of my scripts have RUSTDOCFLAGS=$RUSTFLAGS to prevent this.

    This also explains why adding -Cunsafe-allow-abi-mismatch=sanitizer to RUSTFLAGS doesn't help. This does though:

    RUSTDOCFLAGS=-Cunsafe-allow-abi-mismatch=sanitizer RUSTFLAGS="-Z sanitizer=memory" cargo test -Z build-std --target=x86_64-unknown-linux-gnu
    

    So this is a diagnostic problem.

  12. removed
    A-sanitizersArea: Sanitizers for correctness and code quality
    requires-nightlyThis issue requires a nightly compiler in some way. When possible, use a F-* label instead.
    on Oct 14, 2025
  13. 8 remaining items

  14. added
    A-diagnosticsArea: Messages for errors, warnings, and lints
    C-bugCategory: This is a bug.
    A-ABIArea: Concerning the application binary interface (ABI)
    and removed
    A-ABIArea: Concerning the application binary interface (ABI)
    on Oct 14, 2025
  15. djc commented on Oct 15, 2025

    @djc
    ContributorAuthor

    @saethlin thanks a lot for digging in! This allowed me to make some progress.

    First, I still needed -Cunsafe-allow-abi-mismatch=sanitizer in RUSTFLAGS as well, otherwise it complained about build_script_build targets.

    Second, I'm now getting this error:

    error: failed to run custom build command for `compiler_builtins v0.1.160 (/home/circleci/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/compiler-builtins/compiler-builtins)`
    
    Caused by:
      process didn't exit successfully: `/home/circleci/project/target/debug/build/compiler_builtins-9899e1b0fc09e9f4/build-script-build` (exit status: 1)
      --- stdout
      cargo::rerun-if-changed=build.rs
      cargo::rerun-if-changed=configure.rs
    
      --- stderr
      ==4238==WARNING: MemorySanitizer: use-of-uninitialized-value
          #0 0x55c19c2eee4f  (/home/circleci/project/target/debug/build/compiler_builtins-9899e1b0fc09e9f4/build-script-build+0xe4e4f) (BuildId: 70be73c5757f295b1d4a95b89ef4ac1189242b81)
          #1 0x55c19c2dec2d  (/home/circleci/project/target/debug/build/compiler_builtins-9899e1b0fc09e9f4/build-script-build+0xd4c2d) (BuildId: 70be73c5757f295b1d4a95b89ef4ac1189242b81)
          #2 0x55c19c2f289f  (/home/circleci/project/target/debug/build/compiler_builtins-9899e1b0fc09e9f4/build-script-build+0xe889f) (BuildId: 70be73c5757f295b1d4a95b89ef4ac1189242b81)
          #3 0x55c19c2cdc65  (/home/circleci/project/target/debug/build/compiler_builtins-9899e1b0fc09e9f4/build-script-build+0xc3c65) (BuildId: 70be73c5757f295b1d4a95b89ef4ac1189242b81)
          #4 0x55c19c2cd98a  (/home/circleci/project/target/debug/build/compiler_builtins-9899e1b0fc09e9f4/build-script-build+0xc398a) (BuildId: 70be73c5757f295b1d4a95b89ef4ac1189242b81)
          #5 0x55c19c3053df  (/home/circleci/project/target/debug/build/compiler_builtins-9899e1b0fc09e9f4/build-script-build+0xfb3df) (BuildId: 70be73c5757f295b1d4a95b89ef4ac1189242b81)
          #6 0x55c19c2cd94e  (/home/circleci/project/target/debug/build/compiler_builtins-9899e1b0fc09e9f4/build-script-build+0xc394e) (BuildId: 70be73c5757f295b1d4a95b89ef4ac1189242b81)
          #7 0x55c19c2e4cb6  (/home/circleci/project/target/debug/build/compiler_builtins-9899e1b0fc09e9f4/build-script-build+0xdacb6) (BuildId: 70be73c5757f295b1d4a95b89ef4ac1189242b81)
          #8 0x7fbfa66a2d8f  (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d)
          #9 0x7fbfa66a2e3f  (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d)
          #10 0x55c19c255c84  (/home/circleci/project/target/debug/build/compiler_builtins-9899e1b0fc09e9f4/build-script-build+0x4bc84) (BuildId: 70be73c5757f295b1d4a95b89ef4ac1189242b81)
    
      SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/circleci/project/target/debug/build/compiler_builtins-9899e1b0fc09e9f4/build-script-build+0xe4e4f) (BuildId: 70be73c5757f295b1d4a95b89ef4ac1189242b81) 
      Exiting
    warning: build failed, waiting for other jobs to finish...

    Is this worth an issue against compiler-builtins? Or maybe there is a suppression mechanism somewhere...

  16. saethlin commented on Oct 15, 2025

    @saethlin
    Member

    I led you astray. Using -Zbuild-std without --target makes Cargo rebuild the standard library but doesn't put it into cross-compilation mode, which leads to the RUSTFLAGS being applied to host builds (proc macros and build scripts) but they are still built against the precompiled sysroot.

    AddressSanitizer supports partially-instrumented builds, and MemorySanitizer does not. These false positives are the outcome, and there are handful of closed issues on the tracker of people filing bugs against the standard library because the toolchain let them misconfigure a build and get a report that looks like a true positive, but isn't. You are using -Cunsafe-allow-abi-mismatch to bypass the check that was written to prevent this situation :p

  17. djc commented on Oct 15, 2025

    @djc
    ContributorAuthor

    Thanks a lot! Was finally able to fix hashlink CI so we can get updates rolling again.

  18. Thomasdezeeuw commented on Oct 15, 2025

    @Thomasdezeeuw
    Contributor

    Seems like this is the same issue as #146465?

    Anyone looking for a quick fix using --all-targets skips the tests for docs, so:

    cargo test --all-targets -Z build-std --all-features --target $(TARGET)
    
  19. saethlin commented on Oct 15, 2025

    @saethlin
    Member

    Yes, if djc actually wants to run doctests, that would be #146465. I still think there is a diagnostic problem here, we shouldn't have diagnostics that lead to the confusion reported in the original issue description:

    Note that I already added the suppression option, but it doesn't seem to take effect here?

  20. gendx commented on Oct 22, 2025

    @gendx
    Contributor

    Note that I already added the suppression option, but it doesn't seem to take effect here?

    If the error is about a doctest (not enough context to tell because the error message you pasted doesn't show the line at which the error occurs), you should add the suppression option to RUSTDOCFLAGS, not RUSTFLAGS. Perhaps that's where the confusion is coming from?

  21. saethlin commented on Oct 22, 2025

    @saethlin
    Member

    That has already been mentioned in #147394 (comment) but be aware that GitHub is hiding most of this thread because of the backlinks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-ABIArea: Concerning the application binary interface (ABI)A-diagnosticsArea: Messages for errors, warnings, and lintsC-bugCategory: This is a bug.F-target_modifiers`#![feature(target_modifiers)]`T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions