Resolve memory leaks in tests reported by miri#24979
Open
chescock wants to merge 4 commits into
Open
Conversation
hymm
reviewed
Jul 13, 2026
…ally called. Use `DropCk` in the other test for consistency.
Zeophlite
reviewed
Jul 14, 2026
Zeophlite
approved these changes
Jul 14, 2026
Co-authored-by: Daniel Skates <zeophlite@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Objective
Make it possible to run miri with memory leak detection enabled. It is enabled by default, so it reports errors whenever I run it locally. And running it in CI should help prevent any new leaks from being introduced.
See #4310 and #4959 for previous attempts to enable this. Note that miri has added backtraces to leaked allocations since then (rust-lang/rust#109061), so leaks are much easier to diagnose.
Solution
The first leak: When trying to drop non-send data on the wrong thread, the allocation for the value was being leaked. We can't drop the value from the wrong thread, but we could still deallocate its storage.
Rework the thread check in
NonSendData::dropso that it still deallocates, settingpresent = falseto ensure the value'sdropis not called. Change thepanic!to awarn!so that we can have the check work the same way during unwinding.The second leak: The tests for
Internedintentionally leak data! So we can't exactly "fix" them, but I'd like miri to stop failing on them. Then I realized that miri does not report leaks for our use ofInternedfor things likeScheduleLabel. That's because those values are stored in astatic, so are still reachable.So, add a
staticto each of the tests with intentional leaks and store the leaked values there. miri will consider those values reachable, and not report any leaks.