You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Proc Macro Crate and Workspace Miri and Clippy Malloc Error #92185
When compiling a workspace that has a proc macro crate in it, rustc emits a malloc error causing tools such as miri and clippy to fail. This bug affects nightly versions 2021-12-05+.
I expected to see this happen:
Miri and clippy successfully assess my code
Instead, this happened:
the following crashes (I can supply the actual Mac IPS files if it would be more helpful than these txt copies): clippy.txt miri.txt
I've been trying to dig into this some. I bisected to #91505, and I've been trying to bisect within that rollup, but I'm not really finding out much. I'm still trying to go through them, it is a pretty slow process.
I'm a bit at a loss. Reverting #91385 makes the problem go away (both here and my tests with #92173). However, that PR is not doing anything that should affect any of this, since it is only within an error path. So my best guess is that PR shuffles the code layout/generation just enough to trigger the underlying issue.
cc @rust-lang/clippy and @rust-lang/miri just as a heads up that clippy and miri are crashing on macOS. I haven't tested RLS, but I would imagine it might also have issues.
I would be reluctant to enable jemalloc in miri and clippy. I don't know what is causing the underlying error. However, that is a route we could take. It would involve replicating all of this in their respective main binaries. I'm having dejavu about this, but I don't remember where I last discussed this.
I'm a bit at a loss. Reverting #91385 makes the problem go away
At least that is consistent with the regression range from rust-lang/miri#1941.
Miri itself acts as rustc for proc-macros, but it seems (I was not aware of that) it is a different rustc than the "real" one -- it does not use jemalloc? So yeah I assume this is the same as #92173. Though I also assume that just masks the error since jemalloc doesn't do the realloc check that leads to the abort. That's my guess anyway.
I just want to report that issue is currently blocking me in development. If there are any work around for the macos darwin tool chain and clippy errors... would love to hear about it.
Updating the Cargo.toml files in the workspace to rust edition 2024 and resolver = 3, this builds with the latest stable version of cargo 1.99.0 and also runs "cargo miri test" with only 2 irrelevant warnings ("unit tests of proc-macro crates are executed outside Miri" and "doc tests of proc-macro crates are not supported by Miri") and no errors, using Miri version: miri 0.1.0 (6f5da40 2026-10-10) and:
% cargo -vV
cargo 1.101.0-nightly (29c5daa1a 2026-10-07)
release: 1.101.0-nightly
commit-hash: 29c5daa1afc262323364e039bb70c83372cc702c
commit-date: 2026-10-07
host: aarch64-apple-darwin
libgit2: 1.9.6 (sys:0.21.0 vendored)
libcurl: 8.7.1 (sys:0.4.90+curl-8.21.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 3.6.3 9 Jun 2026
os: Mac OS 27.0.1 [64-bit]
This would seem to imply the issue has been solved, but I note there is some indication the failure maybe sporadic which may indicate I just haven't run the test enough times to se it fail?
Activity
[-]Compiling a Workspace with a macro c[/-][+]Proc Macro Crate and Workspace Miri and Clippy Malloc Error[/+]hkratz commentedon Dec 22, 2021
Looks like it is during proc macro compilation, not execution? Shouldn't that use jemalloc instead of the system malloc?
The error message is the same as in #92173.
ehuss commentedon Dec 22, 2021
clippy and miri are not built with jemalloc.
I think this is likely the same as #92173.
I've been trying to dig into this some. I bisected to #91505, and I've been trying to bisect within that rollup, but I'm not really finding out much. I'm still trying to go through them, it is a pretty slow process.
ehuss commentedon Dec 22, 2021
I'm a bit at a loss. Reverting #91385 makes the problem go away (both here and my tests with #92173). However, that PR is not doing anything that should affect any of this, since it is only within an error path. So my best guess is that PR shuffles the code layout/generation just enough to trigger the underlying issue.
cc @rust-lang/clippy and @rust-lang/miri just as a heads up that clippy and miri are crashing on macOS. I haven't tested RLS, but I would imagine it might also have issues.
I would be reluctant to enable jemalloc in miri and clippy. I don't know what is causing the underlying error. However, that is a route we could take. It would involve replicating all of this in their respective main binaries. I'm having dejavu about this, but I don't remember where I last discussed this.
RalfJung commentedon Dec 23, 2021
I assume this is the same problem as rust-lang/miri#1941
RalfJung commentedon Dec 23, 2021
At least that is consistent with the regression range from rust-lang/miri#1941.
Miri itself acts as rustc for proc-macros, but it seems (I was not aware of that) it is a different rustc than the "real" one -- it does not use jemalloc? So yeah I assume this is the same as #92173. Though I also assume that just masks the error since jemalloc doesn't do the realloc check that leads to the abort. That's my guess anyway.
rdornin commentedon Mar 18, 2022
I just want to report that issue is currently blocking me in development. If there are any work around for the macos darwin tool chain and clippy errors... would love to hear about it.
RodBurman commentedon Oct 11, 2026
Updating the Cargo.toml files in the workspace to rust edition 2024 and resolver = 3, this builds with the latest stable version of cargo 1.99.0 and also runs "cargo miri test" with only 2 irrelevant warnings ("unit tests of
proc-macrocrates are executed outside Miri" and "doc tests ofproc-macrocrates are not supported by Miri") and no errors, using Miri version: miri 0.1.0 (6f5da40 2026-10-10) and:This would seem to imply the issue has been solved, but I note there is some indication the failure maybe sporadic which may indicate I just haven't run the test enough times to se it fail?
RalfJung commentedon Oct 11, 2026
FWIW this is what we have done since then in Miri, and AFAIK also in clippy.
So yeah I think this can be closed.