Skip to content

ICE: assertion failed: ptr::eq(context.tcx.gcx as *const _ as *const (), tcx.gcx as *const _ as *const ()), compiler/rustc_middle/src/ty/context/tls.rs #110564

Description

@Nashenas88

Code

Something in the standard library. We caught this in our integration pipeline.

Meta

rustc --version --verbose:

1.71.0-nightly (9c51cf7e7 2023-04-19) running on x86_64-apple-darwin

Error output

Building stage2 library artifacts (x86_64-apple-darwin -> x86_64-unknown-linux-gnu)
   Compiling cc v1.0.77
   Compiling core v0.0.0 (/opt/s/w/ir/x/w/fuchsia-third_party-rust/library/core)
   Compiling libc v0.2.140
   Compiling memchr v2.5.0
   Compiling std v0.0.0 (/opt/s/w/ir/x/w/fuchsia-third_party-rust/library/std)
   Compiling compiler_builtins v0.1.91
   Compiling unwind v0.0.0 (/opt/s/w/ir/x/w/fuchsia-third_party-rust/library/unwind)
   Compiling profiler_builtins v0.0.0 (/opt/s/w/ir/x/w/fuchsia-third_party-rust/library/profiler_builtins)
thread 'rustc' panicked at 'assertion failed: ptr::eq(context.tcx.gcx as *const _ as *const (),\n    tcx.gcx as *const _ as *const ())', /opt/s/w/ir/x/w/fuchsia-third_party-rust/compiler/rustc_middle/src/ty/context/tls.rs:126:9
stack backtrace:
   0: rust_begin_unwind
             at ./library/std/src/panicking.rs:578:5
   1: core::panicking::panic_fmt
             at ./library/core/src/panicking.rs:67:14
   2: core::panicking::panic
             at ./library/core/src/panicking.rs:117:5
   3: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::queries::region_scope_tree, rustc_query_impl::plumbing::QueryCtxt>
   4: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::region_scope_tree
   5: <rustc_hir_typeck::fn_ctxt::FnCtxt>::resolve_rvalue_scopes
   6: rustc_hir_typeck::typeck
   7: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::queries::typeck, rustc_query_impl::plumbing::QueryCtxt>
   8: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::typeck
   9: rustc_hir_typeck::typeck_item_bodies
  10: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::queries::typeck_item_bodies, rustc_query_impl::plumbing::QueryCtxt>
  11: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::typeck_item_bodies
  12: rustc_hir_analysis::check_crate
  13: rustc_interface::passes::analysis
  14: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::queries::analysis, rustc_query_impl::plumbing::QueryCtxt>
  15: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::analysis
  16: <rustc_interface::queries::QueryResult<&rustc_middle::ty::context::GlobalCtxt>>::enter::<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure#1}::{closure#2}::{closure#4}>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md
note: rustc 1.71.0-nightly (9c51cf7e7 2023-04-19) running on x86_64-apple-darwin
note: compiler flags: --crate-type lib -C opt-level=3 -C embed-bitcode=no -C codegen-units=1 -C debuginfo=2 -Z unstable-options -C linker=/opt/s/w/ir/x/w/cipd/bin/clang++ -C link-arg=--target=x86_64-unknown-linux-gnu -C link-arg=--sysroot=/opt/s/w/ir/x/w/cipd/linux -C link-arg=-fuse-ld=lld -C link-arg=-Wl,--undefined-version -C symbol-mangling-version=legacy -Z unstable-options -Z unstable-options -Z macro-backtrace -C link-args=-Wl,-z,origin -C link-args=-Wl,-rpath,$ORIGIN/../lib -C split-debuginfo=unpacked -C prefer-dynamic -Z inline-mir -C embed-bitcode=yes -Z crate-attr=doc(html_root_url="https://doc.rust-lang.org/nightly/") -Z binary-dep-depinfo -Z force-unstable-if-unmarked
note: some of the compiler flags provided by cargo are hidden
query stack during panic:
#0 [typeck] type-checking `num::flt2dec::to_shortest_exp_str`
#1 [typeck_item_bodies] type-checking all item bodies
#2 [analysis] running analysis passes on this crate
end of query stack
error: could not compile `core`

Link to full build output here.

Backtrace

stack backtrace:
   0: rust_begin_unwind
             at ./library/std/src/panicking.rs:578:5
   1: core::panicking::panic_fmt
             at ./library/core/src/panicking.rs:67:14
   2: core::panicking::panic
             at ./library/core/src/panicking.rs:117:5
   3: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::queries::region_scope_tree, rustc_query_impl::plumbing::QueryCtxt>
   4: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::region_scope_tree
   5: <rustc_hir_typeck::fn_ctxt::FnCtxt>::resolve_rvalue_scopes
   6: rustc_hir_typeck::typeck
   7: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::queries::typeck, rustc_query_impl::plumbing::QueryCtxt>
   8: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::typeck
   9: rustc_hir_typeck::typeck_item_bodies
  10: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::queries::typeck_item_bodies, rustc_query_impl::plumbing::QueryCtxt>
  11: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::typeck_item_bodies
  12: rustc_hir_analysis::check_crate
  13: rustc_interface::passes::analysis
  14: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::queries::analysis, rustc_query_impl::plumbing::QueryCtxt>
  15: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::analysis
  16: <rustc_interface::queries::QueryResult<&rustc_middle::ty::context::GlobalCtxt>>::enter::<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure#1}::{closure#2}::{closure#4}>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Activity

  1. added
    C-bugCategory: This is a bug.
    I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    on Apr 19, 2023
  2. Nashenas88 commented on Apr 19, 2023

    @Nashenas88
    ContributorAuthor

    This occurred after testing the change at commit 9c51cf7. This is also occurring only on our mac builder. So far only one instance.

  3. changed the title [-]ICE while compiling the compiler[/-] [+]ICE: assertion failed: ptr::eq(context.tcx.gcx as *const _ as *const (), tcx.gcx as *const _ as *const ()), compiler/rustc_middle/src/ty/context/tls.rs[/+] on Apr 20, 2023
  4. pinned this issue on Apr 20, 2023
  5. unpinned this issue on Apr 20, 2023
  6. Noratrieb commented on Apr 21, 2023

    @Noratrieb
    Member

    Are you able to consistently reproduce the issue, and only after that commit?

  7. Noratrieb commented on Apr 21, 2023

    @Noratrieb
    Member

    This is a sanity assertion that should never be hit. It implies that there are two global contexts in the compilation session, which makes no sense. It's entirely possible that stage2 rustc is getting miscompiled. Do you have any weird configs?

  8. jyn514 commented on Apr 21, 2023

    @jyn514
    Member

    @Nashenas88 if you are hitting this reliably, can you apply this diff and post the new ICE message? I'd expect it to show the same numerical values for both pointers.

    diff --git a/compiler/rustc_middle/src/ty/context/tls.rs b/compiler/rustc_middle/src/ty/context/tls.rs
    index fb0d909307e..f2a93ea7e25 100644
    --- a/compiler/rustc_middle/src/ty/context/tls.rs
    +++ b/compiler/rustc_middle/src/ty/context/tls.rs
    @@ -126,7 +126,7 @@ pub fn with_related_context<'tcx, F, R>(tcx: TyCtxt<'tcx>, f: F) -> R
             assert!(ptr::eq(
                 context.tcx.gcx as *const _ as *const (),
                 tcx.gcx as *const _ as *const ()
    -        ));
    +        ), "{:?} != {:?}", context.tcx.gcx as *const _, tcx.gcx as *const _);
     
             let context: &ImplicitCtxt<'_, '_> = unsafe { mem::transmute(context) };
     
  9. jyn514 commented on Apr 21, 2023

    @jyn514
    Member

    all those options look pretty reasonable; the only thing that stands out is that we don't test lto = fat, but I'm not aware of it being broken.

  10. Noratrieb commented on Apr 21, 2023

    @Noratrieb
    Member

    Why are you using fat LTO in the first place? Have you measured the performance impact (or binary size impact)? ThinLTO was measured to be faster: #103453

  11. tmandry commented on Apr 21, 2023

    @tmandry
    Member

    We were following #101403 and must've missed that that was using thin instead of fat, or just assumed fat would be faster. We can always switch to thin.

    I wouldn't expect that to explain this assertion failure though, unless LLVM is just doing a memory corruption in rustc. EDIT: Oh, a miscompile in the LTO pipeline could certainly explain it

  12. tmandry commented on Apr 21, 2023

    @tmandry
    Member

    Still though, I find it fairly alarming that there would be a miscompile in rustc using supported options.

  13. added
    E-needs-mcveCall for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example
    S-needs-reproStatus: This issue has no reproduction and needs a reproduction to make progress.
    and removed
    E-needs-mcveCall for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example
    on Dec 2, 2024
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-LTOArea: Link-time optimization (LTO)C-bugCategory: This is a bug.I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️S-needs-reproStatus: This issue has no reproduction and needs a reproduction to make progress.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