Add a backtrace to Allocation, display it in leak reports - #109061
Conversation
|
(rustbot has picked a reviewer for you, use r? to override) |
|
Failed to set assignee to
|
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
|
⌛ Trying commit f333ee50016e250b849f35947483f3e28989e3e0 with merge 0a70014f8cc287d3eee38518da13127b0eca278e... |
|
☀️ Try build successful - checks-actions |
1 similar comment
|
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (0a70014f8cc287d3eee38518da13127b0eca278e): comparison URL. Overall result: ❌ regressions - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
|
Based on the cachegrind diff, I believe the regressions above are legitimate and caused by this change. This new commit may fix them. |
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
|
⌛ Trying commit c994d6d0f210fd2c4b6bca144347f90299e010cc with merge 77af1a06420c9a7b396987192c44bcd1e4b46bda... |
|
☀️ Try build successful - checks-actions |
1 similar comment
|
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (77af1a06420c9a7b396987192c44bcd1e4b46bda): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
|
Based on the cachegrind diffs all the perf results are optimization instability, they don't have anything to with |
3ebe6e7 to
ba7675b
Compare
83b9000 to
6770c2c
Compare
|
I added a flag that does the thing and a test for it. I "blessed" the test with |
6770c2c to
cd305dd
Compare
|
I rebased to pull in the fix that makes Miri tests work again, and re-blessed the middle commit. |
|
@bors r+ |
|
📌 Commit cd305dd21938dcce7d79a24b17949327ee088ba1 has been approved by It is now in the queue for this repository. |
This comment has been minimized.
This comment has been minimized.
|
32-bit tests 🤦 |
Co-authored-by: Ralf Jung <post@ralfj.de>
cd305dd to
fb68292
Compare
|
@bors r=oli-obk |
|
☀️ Test successful - checks-actions |
1 similar comment
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (23eb90f): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
# 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 bevyengine#4310 and bevyengine#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::drop` so that it still deallocates, setting `present = false` to ensure the value's `drop` is not called. Change the `panic!` to a `warn!` so that we can have the check work the same way during unwinding. The second leak: The tests for `Interned` intentionally 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 of `Interned` for things like `ScheduleLabel`. That's because those values are stored in a `static`, so are still reachable. So, add a `static` to each of the tests with intentional leaks and store the leaked values there. miri will consider those values reachable, and not report any leaks. --------- Co-authored-by: Daniel Skates <zeophlite@gmail.com>
This addresses rust-lang/miri#2813
Information like this from diagnostics is indispensable for diagnosing problems that are difficult to reproduce such as https://github.com/rust-lang/miri-test-libstd/actions/runs/4395316008/jobs/7697019211#step:4:770 (which has not been reproduced or diagnosed).