-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
"malloc_consolidate(): unaligned fastbin chunk detected" when attempting to block single-threaded runtime #6452
Comments
Have you tried running this under miri or valgrind? |
Under valgrind it doesn't crash. It complains about a few things, but not sure if they are false positive or not:
|
Yeah, that looks like memory corruption. They're not just false positives. You have a use-after-free or double-free somewhere. Most likely, the stack trace you reported here happens much later than the actual problem. That is, the allocator is corrupted at some earlier point, and the panic inside Tokio is just when the corruption is noticed later. I think it's probably likely that the problem is in your own unsafe code. |
That is a reasonable assumption, but I don't have UPD: Can't use MIni for now:
|
Do I read valgrind correctly that it indicates an issue in |
The valgrind output indicates that the use-after-free happened in the futures crate. But that doesn't necessarily mean that the bug is in the futures crate.
If I search for "unsafe" in your repository, there are 32 results. |
Ah, yes, all of that code was audited to be correct, but either way the crate I pointed to specifically is isolated and not relying on any of the code from other parts of the repository. |
How about adding some printlns to the destructors of relevant objects (e.g. that |
Closing due to inactivity. I still don't think this is likely to be a bug in Tokio. |
Version
List the versions of all
tokio
crates you are using. The easiest way to getthis information is using
cargo tree
subcommand:Platform
Ubuntu 22.04
Description
I have a piece of broken code that results in the following unfortunate situation:
I tried this code:
Unfortunately I was not able to reduce the code yet, but here is the commit: nazar-pc/subspace@a761589
Specifically
#[tokio::test]
is problematic, when replaced with#[tokio::test(flavor = "multi_thread")]
the problem goes away.Here is backtrace in gdb:
Specifically the code where it panics looks like this:
I expected to see this happen:
The panic is correct and fair, but it should not lead to memory issues.
The text was updated successfully, but these errors were encountered: