test: Add a regression test for Apple platforms aborting on `free` by tgross35 · Pull Request #155713 · rust-lang/rust

tgross35 · 2026-04-24T02:16:24Z

Add a regression test for #150898 to make users aware that if this test failures, they may encounter unusual behavior elsewhere.

rustbot · 2026-04-24T02:16:38Z

r? @adwinwhite

rustbot has assigned @adwinwhite.
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

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 73 candidates
Random selection from 19 candidates

tgross35 · 2026-04-24T02:16:45Z

@bors try jobs=aarch64-apple

test: Add a regression test for Apple platforms aborting on `free` try-job: aarch64-apple

rust-bors · 2026-04-24T02:25:45Z

💔 Test for eb1af91 failed: CI. Failed job:

try - aarch64-apple (web logs, enhanced plaintext logs)

tgross35 · 2026-04-24T02:28:16Z

Blocked of course if the runner in CI fails.

@dianqk this is just your repro from #150898 (comment).

test: Add a regression test for Apple platforms aborting on `free` try-job: aarch64-apple

dianqk · 2026-04-24T05:40:47Z

+// bug. If this fails with SIGABRT, you may need to upgrade your system to
+// avoid other unexpected behavior.
+//
+// The bug was resolved by MacOS 26.4.


Suggested change

// The bug was resolved by MacOS 26.4.

// The bug was resolved by macOS 26.4.

View changes since the review

dianqk · 2026-04-24T05:47:15Z

+#[unsafe(no_mangle)]
+fn retv() -> Reproducer {
+    // let x = [48, 0, 3, 1, 48, 0];
+    let x = [0, 0, 3, 0, 0, 0];


I don't know if this can pass Miri check. Should we use let x = [48, 0, 3, 1, 48, 0];?

View changes since the review

I replaced the test case with something that I think should be less reliant on codegen, based on your asm repro. I found that using threads makes it reproduce is every time, or at least hasn't not crashed in the
30-40 times I've run it.

dianqk · 2026-04-24T05:51:26Z

+
+        let s = 128;
+        // A few more allocations seem to be necessary, probably to prime
+        // the allocator find the bug.


Should we document that this test can be a flaky test?

View changes since the review

Mentioned this in the comment that it can have false negatives but is also pretty reliable

test: Add a regression test for Apple platforms aborting on `free` try-job: aarch64-apple

tgross35 · 2026-04-24T09:43:14Z

Any idea what the actual failure mechanism is in the buggy allocator? I can't wrap my head around how writing a random value to a (should be) valid allocation could cause free to not work.

rust-bors · 2026-04-24T12:43:48Z

☀️ Try build successful (CI)
Build commit: fa6c504 (fa6c504d6bea64e370fd51fe3a340feeec21811e, parent: d493b7c5ac637ed7edf626128b9f14796a2dad20)

dianqk · 2026-04-24T13:20:26Z

Any idea what the actual failure mechanism is in the buggy allocator? I can't wrap my head around how writing a random value to a (should be) valid allocation could cause free to not work.

I have no idea. Really. And I don't think Apple will share this bug.

dianqk · 2026-04-24T13:20:36Z

@bors r+ rollup

rust-bors · 2026-04-24T13:20:40Z

📌 Commit 150905c has been approved by dianqk

It is now in the queue for this repository.

…=dianqk test: Add a regression test for Apple platforms aborting on `free` Add a regression test for rust-lang#150898 to make users aware that if this test failures, they may encounter unusual behavior elsewhere.

…uwer Rollup of 12 pull requests Successful merges: - #149452 (Refactor out common code into a `IndexItem::new` constructor) - #155621 (Document #[diagnostic::on_move] in the unstable book.) - #155635 (delegation: rename `Self` generic param to `This` in recursive delegations) - #155730 (Some cleanups around per parent disambiguators) - #153537 (rustc_codegen_ssa: Define ELF flag value for sparc-unknown-linux-gnu) - #155219 (Do not suggest borrowing enclosing calls for nested where-clause obligations) - #155408 (rustdoc: Fix Managarm C Library name in cfg pretty printer) - #155571 (Enable AddressSanitizer on arm-unknown-linux-gnueabihf and armv7-unknown-linux-gnueabihf) - #155713 (test: Add a regression test for Apple platforms aborting on `free`) - #155723 (Fix tier level for 5 thumb bare-metal ARM targets) - #155735 (Fix typo by removing extra 'to') - #155736 (Remove `AllVariants` workaround for rust-analyzer)

Rollup merge of #155713 - tgross35:150898-regression-test, r=dianqk test: Add a regression test for Apple platforms aborting on `free` Add a regression test for #150898 to make users aware that if this test failures, they may encounter unusual behavior elsewhere.

DKLoehr · 2026-05-01T18:36:55Z

We started hitting this test in chromium, and it's not clear what the right thing for us to do is. This appears to be testing the system that builds the compiler, not the one it actually runs on, so it's not clear if it's really applicable. Since it only seems to reproduce in specific circumstances anyway, we've disabled the test for now; is the expectation just that anyone distributing rustc will disable the test when packaging it?

tgross35 · 2026-05-01T20:18:16Z

Disabling it or marking xfail is reasonable if you are unable to upgrade your MacOS version. I added this test because we've seen some spurious crashes and we need a way to be sure they aren't coming from the buggy platform. For your downstream purpose I suppose it's just an FYI that you have a chance of hitting the random abort.

nico · 2026-05-04T01:36:53Z

If the action is "disable the test", how is it useful to have a test that just fails on platforms earlier than macOS 26.4? Also, don't most people use prebuilt rustc binaries?

The linked #150898 only affects macOS 26 (before 26.4) from what I can tell, but this test is failing on earlier macOS versions as well.

Is the takeaway here that rustc produces binaries that can crash on macOS before 26.4 and there's nothing people can do about it? Something else? Just to confirm, the bug is about run-time behavior of compiled code, not of rustc itself crashing?

In short, I suppose my question is "what problem does this solve?".

Sorry about being confused about so many things 😅

tgross35 · 2026-05-04T21:20:16Z

If the action is "disable the test", how is it useful to have a test that just fails on platforms earlier than macOS 26.4? > Also, don't most people use prebuilt rustc binaries?

The action is "upgrade the buggy OS". If this really isn't possible then yes, all you can really do is hide the problem and hope you don't hit related bugs.

Just to confirm, the bug is about run-time behavior of compiled code, not of rustc itself crashing?

Generally yes, this has shown up in builds other than rustc. But we also have no way of guaranteeing that there isn't a codepath within rustc that may hit this, now or at some point in the future. Or that codegen changes won't mean this problem gets hit in places it wasn't before. (Not rustc-specific of course since this bug can be hit from any language.)

In short, I suppose my question is "what problem does this solve?".

From above:

I added this test because we've seen some spurious crashes and we need a way to be sure they aren't coming from the buggy platform.

Without this test, if we hit a bug that looks like it could be caused by the issue here, we have no way of knowing whether it's a bug on our end or in the platform. #155518 is one real example.

nico · 2026-05-05T19:51:14Z

upgrade the buggy OS

But the person building rustc (or, worse, a program compiled by rustc) for distribution has no control over the OS it (or its output) runs on.

tgross35 · 2026-05-05T20:10:36Z

I don't know how to improve that situation. If it's that important then I guess you could look at LLVM changes to avoid emitting the bad pattern when building for MacOS? But that really doesn't seem worth the effort.

Are you hitting the free crashes in your builds? Or what's the real-world concern here?

nico · 2026-05-05T20:46:03Z

We're building a rustc binary. We're now disabling this test: https://chromium-review.googlesource.com/c/chromium/src/+/7808009/2/tools/rust/build_rust.py

I imagine everyone else building and distributing a rustc binary will also have to disable it.

This doesn't seem very useful to me is all :) I was hoping I was missing something.

(Since we disabled the test, we're not blocked on anything here.)

tgross35 · 2026-05-05T20:52:16Z

I imagine everyone else building and distributing a rustc binary will also have to disable it.

Only if you CI is truly stuck on the version. I assume that can't be very many people for very long since AIUI this was only present on 26.0(?)-26.4, which has been out for over a month at this point. But yes, this test's main purpose is helping narrow other test failures, that's less useful downstream than in-repo.

nico · 2026-05-05T21:21:48Z

Ah, if the intent is for this to say "other tests might fail", then that makes sense. Sorry it took me a while to understand, thanks for patiently explaining.

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 24, 2026

tgross35 marked this pull request as ready for review April 24, 2026 02:16

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 24, 2026

rustbot assigned adwinwhite Apr 24, 2026

rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Apr 24, 2026