Skip to content

Conversation

@hkBst
Copy link
Member

@hkBst hkBst commented Dec 26, 2025

This is extracted from #150344 to see if it is the cause of the Miri failure.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Dec 26, 2025
@rustbot
Copy link
Collaborator

rustbot commented Dec 26, 2025

r? @jhpratt

rustbot has assigned @jhpratt.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-miri failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)
tests/pass/shims/x86/rounding-error.rs ... ok
tests/pass/shims/x86/intrinsics-x86-gfni.rs ... ok

FAILED TEST: tests/pass/both_borrows/basic_aliasing_model.rs (revision `stack`)
command: MIRI_ENV_VAR_TEST="0" MIRI_TEMP="/tmp/miri-uitest-9CIwzC" RUST_BACKTRACE="1" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/miri" "--error-format=json" "--sysroot=/checkout/obj/build/x86_64-unknown-linux-gnu/miri-sysroot" "-Dwarnings" "-Dunused" "-Ainternal_features" "-Zui-testing" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/tmp/miri_ui/0/tests/pass/both_borrows" "tests/pass/both_borrows/basic_aliasing_model.rs" "--edition" "2021" "--cfg=stack" "-Cextra-filename=stack"

error: test got exit status: 1, but expected 0
 = note: compilation failed, but was expected to succeed

error: no output was expected
Execute `./miri test --bless` to update `tests/pass/both_borrows/basic_aliasing_model.stack.stderr` to the actual output
+++ <stderr output>
error: Undefined Behavior: trying to retag from <5633> for SharedReadWrite permission at alloc2217[0x0], but that tag does not exist in the borrow stack for this location
##[error]  --> tests/pass/both_borrows/basic_aliasing_model.rs:272:9
   |
LL |         c.set(2);
   |         ^ this error occurs as part of retag at alloc2217[0x0..0x4]
   |
   = help: this indicates a potential bug in the program: it performed an invalid operation, but the Stacked Borrows rules it violated are still experimental
   = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
help: <5633> was created by a SharedReadWrite retag at offsets [0x0..0x4]
  --> tests/pass/both_borrows/basic_aliasing_model.rs:268:17
   |
LL |         let c = &*raw;
   |                 ^^^^^
help: <5633> was later invalidated at offsets [0x0..0x4] by a write access
  --> tests/pass/both_borrows/basic_aliasing_model.rs:271:9
   |
LL |         *d = 1;
   |         ^^^^^^
   = note: BACKTRACE (of the first span):
---



full stderr:
error: Undefined Behavior: trying to retag from <5633> for SharedReadWrite permission at alloc2217[0x0], but that tag does not exist in the borrow stack for this location
##[error]  --> tests/pass/both_borrows/basic_aliasing_model.rs:272:9
   |
LL |         c.set(2);
   |         ^ this error occurs as part of retag at alloc2217[0x0..0x4]
   |
   = help: this indicates a potential bug in the program: it performed an invalid operation, but the Stacked Borrows rules it violated are still experimental
   = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
help: <5633> was created by a SharedReadWrite retag at offsets [0x0..0x4]
  --> tests/pass/both_borrows/basic_aliasing_model.rs:268:17
   |
LL |         let c = &*raw;
   |                 ^^^^^
help: <5633> was later invalidated at offsets [0x0..0x4] by a write access
  --> tests/pass/both_borrows/basic_aliasing_model.rs:271:9
   |
LL |         *d = 1;
   |         ^^^^^^
   = note: BACKTRACE (of the first span):
---



FAILED TEST: tests/pass/issues/issue-miri-3473.rs (revision `stack`)
command: MIRI_ENV_VAR_TEST="0" MIRI_TEMP="/tmp/miri-uitest-9CIwzC" RUST_BACKTRACE="1" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/miri" "--error-format=json" "--sysroot=/checkout/obj/build/x86_64-unknown-linux-gnu/miri-sysroot" "-Dwarnings" "-Dunused" "-Ainternal_features" "-Zui-testing" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/tmp/miri_ui/0/tests/pass/issues" "tests/pass/issues/issue-miri-3473.rs" "--edition" "2021" "--cfg=stack" "-Cextra-filename=stack"

error: test got exit status: 1, but expected 0
 = note: compilation failed, but was expected to succeed

error: no output was expected
Execute `./miri test --bless` to update `tests/pass/issues/issue-miri-3473.stack.stderr` to the actual output
+++ <stderr output>
error: Undefined Behavior: trying to retag from <336> for SharedReadWrite permission at alloc197[0x0], but that tag does not exist in the borrow stack for this location
##[error]  --> tests/pass/issues/issue-miri-3473.rs:25:21
   |
LL |         assert_eq!(*ptr.value(), 0);
   |                     ^^^ this error occurs as part of retag at alloc197[0x0..0x10]
   |
   = help: this indicates a potential bug in the program: it performed an invalid operation, but the Stacked Borrows rules it violated are still experimental
   = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
help: <336> was created by a SharedReadWrite retag at offsets [0x0..0x8]
  --> tests/pass/issues/issue-miri-3473.rs:23:19
   |
LL |         let ptr = &*a;
   |                   ^^^
help: <336> was later invalidated at offsets [0x0..0x8] by a write access
  --> tests/pass/issues/issue-miri-3473.rs:24:9
   |
LL |         *UnsafeCell::raw_get(a.cast::<UnsafeCell<usize>>()) = 2;
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

error: aborting due to 1 previous error



full stderr:
error: Undefined Behavior: trying to retag from <336> for SharedReadWrite permission at alloc197[0x0], but that tag does not exist in the borrow stack for this location
##[error]  --> tests/pass/issues/issue-miri-3473.rs:25:21
   |
LL |         assert_eq!(*ptr.value(), 0);
   |                     ^^^ this error occurs as part of retag at alloc197[0x0..0x10]
   |
   = help: this indicates a potential bug in the program: it performed an invalid operation, but the Stacked Borrows rules it violated are still experimental
   = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
help: <336> was created by a SharedReadWrite retag at offsets [0x0..0x8]
  --> tests/pass/issues/issue-miri-3473.rs:23:19
   |
LL |         let ptr = &*a;
   |                   ^^^
help: <336> was later invalidated at offsets [0x0..0x8] by a write access
  --> tests/pass/issues/issue-miri-3473.rs:24:9
   |
LL |         *UnsafeCell::raw_get(a.cast::<UnsafeCell<usize>>()) = 2;
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

error: aborting due to 1 previous error
---
Location:
   /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ui_test-0.30.3/src/lib.rs:365

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   1: <color_eyre[493a6ae0a0ce9e7e]::config::EyreHook>::into_eyre_hook::{closure#0}<unknown>
      at <unknown source file>:<unknown line>
   2: <eyre[d5668332839c3bef]::Report>::from_adhoc::<&str><unknown>
      at <unknown source file>:<unknown line>
   3: ui_test[912887b752d42bc2]::run_tests_generic::<ui_test[912887b752d42bc2]::default_file_filter, ui[e81db0b9ccea4a15]::run_tests::{closure#1}, alloc[b40735b4d1ab6e1f]::boxed::Box<dyn ui_test[912887b752d42bc2]::status_emitter::StatusEmitter>><unknown>
      at <unknown source file>:<unknown line>
   4: ui[e81db0b9ccea4a15]::ui<unknown>
      at <unknown source file>:<unknown line>
   5: ui[e81db0b9ccea4a15]::main<unknown>
      at <unknown source file>:<unknown line>
   6: std[cb2ff413f9281985]::sys::backtrace::__rust_begin_short_backtrace::<fn() -> core[270b801f3371ff94]::result::Result<(), eyre[d5668332839c3bef]::Report>, core[270b801f3371ff94]::result::Result<(), eyre[d5668332839c3bef]::Report>><unknown>
      at <unknown source file>:<unknown line>
   7: std[cb2ff413f9281985]::rt::lang_start::<core[270b801f3371ff94]::result::Result<(), eyre[d5668332839c3bef]::Report>>::{closure#0}<unknown>
      at <unknown source file>:<unknown line>
   8: std[cb2ff413f9281985]::rt::lang_start_internal<unknown>
      at <unknown source file>:<unknown line>
   9: main<unknown>
      at <unknown source file>:<unknown line>
  10: __libc_start_main<unknown>
      at <unknown source file>:<unknown line>
  11: _start<unknown>
      at <unknown source file>:<unknown line>

Run with COLORBT_SHOW_HIDDEN=1 environment variable to disable frame filtering.
Run with RUST_BACKTRACE=full to include source snippets.
error: test failed, to rerun pass `--test ui`

Caused by:
  process didn't exit successfully: `/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/deps/ui-2ee2b6f0bce42fa9` (exit status: 1)
Command `/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo test --target x86_64-unknown-linux-gnu -Zbinary-dep-depinfo -j 4 -Zroot-dir=/checkout --locked --color=always --release --manifest-path /checkout/src/tools/miri/Cargo.toml -- [workdir=/checkout]` failed with exit code 1
Created at: src/bootstrap/src/core/build_steps/tool.rs:191:21
Executed at: src/bootstrap/src/core/build_steps/test.rs:732:19

Command has failed. Rerun with -v to see more details.
Bootstrap failed while executing `test --stage 2 src/tools/miri src/tools/miri/cargo-miri`
Build completed unsuccessfully in 0:36:45
  local time: Fri Dec 26 08:53:02 UTC 2025
  network time: Fri, 26 Dec 2025 08:53:02 GMT
##[error]Process completed with exit code 1.

@hanna-kruppe
Copy link
Contributor

I haven’t looked at the other PR but this change seems incorrect (forgets the allocator, so it’s impossible to reconstruct the Box<T, A>) and redundant with Box::into_{raw,non_null}_with_allocator (which is correct because it doesn’t forget the allocator).

@hkBst
Copy link
Member Author

hkBst commented Dec 26, 2025

@hanna-kruppe You are correct in that this is in effect Box::into_{raw,non_null}_with_allocator().0. The allocator is not needed, because the collection (LinkedList) stores it for all nodes. Currently it leaks boxes to make this work (and presumably reconstructs them with the stored allocator).

@theemathas
Copy link
Contributor

Is there a reason this generalization is done on Box::into_non_null, but not Box::into_raw?

@theemathas
Copy link
Contributor

theemathas commented Dec 26, 2025

Oh, and making code generic over allocators can sometimes change what UB Miri detects. See rust-lang/miri#3870 for example.

CC @RalfJung

@theemathas theemathas added T-opsem Relevant to the opsem team A-box Area: Our favorite opsem complication labels Dec 26, 2025
@hkBst
Copy link
Member Author

hkBst commented Dec 26, 2025

Is there a reason this generalization is done on Box::into_non_null, but not Box::into_raw?

It's done on both because Box::into_non_null uses Box::into_raw internally.

@RalfJung
Copy link
Member

RalfJung commented Dec 26, 2025

Yeah this breaks the Stacked Borrows logic for turning a Box into a raw pointer. That cannot be done in code which is generic over the allocator since whether or not the Box has noalias semantics unfortunately depends on the presence of the allocator. We haven't been able to reach consensus for removing noalias from Box entirely, and the addition of custom allocators did not take into account aliasing considerations at all. I am, very slowly, working towards deprecating Stacked Borrows in favor of Tree Borrows, but that needs a bunch more work. So for now we are stuck with this mess.

But also, as Hanna said, this PR breaks the API design principles that Box used so far, which is to not implicitly forget the allocator. I'm not in t-libs-api, but this does not seem like a good idea to me.

@hkBst
Copy link
Member Author

hkBst commented Dec 27, 2025

But also, as Hanna said, this PR breaks the API design principles that Box used so far, which is to not implicitly forget the allocator. I'm not in t-libs-api, but this does not seem like a good idea to me.

A NonNull is just a raw pointer with the additional constraint that it is not the null pointer. So if this is not okay for NonNull, then it would also be bad for as_ptr...

Never mind, didn't pay attention again to whether it takes the box by ref or not.

@RalfJung
Copy link
Member

RalfJung commented Dec 27, 2025 via email

@hanna-kruppe
Copy link
Contributor

See also #141219

@hkBst
Copy link
Member Author

hkBst commented Dec 27, 2025

See also #141219

Thanks, I see this change is indeed going against the stated direction, and that direction makes sense. It does seem to force leak into a unique position for which it seems unsuitable. If I want to change a Box into a NonNull, why do I have to leak it first? Perhaps there should be a way to directly get an unmanaged NonNull from an allocator? Or is there already such an API?

@hkBst hkBst closed this Dec 27, 2025
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 27, 2025
@hanna-kruppe
Copy link
Contributor

hanna-kruppe commented Dec 27, 2025

You can use Box::into_non_null_with_allocator and then deal with the allocator that it returns appropriately (e.g., stash it somewhere if it’s needed for deallocation). In the LinkedList case, from glancing over the other PR’s diff, it seems that the allocator used for the node boxes is &A, so it can be ignored (but doing so explicitly is a good chance to leave a comment explaining this subtlety).

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

Labels

A-box Area: Our favorite opsem complication T-libs Relevant to the library team, which will review and decide on the PR/issue. T-opsem Relevant to the opsem team

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants