-
Notifications
You must be signed in to change notification settings - Fork 484
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MIRI detects leaks even when using temporary pool #1072
Comments
Here the log from MIRI execution. |
The allocations all look like crossbeam's own epoch-tracking stuff. Did the versions in your lockfile change from when it used to work? |
Well, I updated my Cargo.toml so it did. This wrapper works when using It could be a bug in crossbeam but I don't use it directly (so it is only transitive dependency from rayon) so I don't know where to dig further. |
The version comment on the playground does nothing -- it's always whatever is prebuilt in the playground sysroot, which will be the latest release (possibly lagging brand new releases). I ran miri at your link, and it timed out the first time, then reported leaks the second time. When I run your reproducer locally under valgrind, it says the memory is still reachable -- I suspect it's the crossbeam-epoch |
rayon
versionrayon = "1.7.0"
Rust version
Code
When running it using command
cargo +nightly miri test
, MIRI reports memory leaks somewhere in rayon or crossbeam, see attached log.I had previously had similar trouble with global threadpool so I created
run_in_rayon
wrapper to ensure that threads created byrayon
aren't leaked and don't cause issues with MIRI but it doesn't work anymore.The text was updated successfully, but these errors were encountered: