Closed nazar-pc closed 1 month ago
Maybe related: https://github.com/rust-lang/futures-rs/issues/2781
Pushed another commit into above branch with a lot of code and dependencies removed, while still reproducing an issue.
There are 2 FuturesUnordered
usages there in redials
and inbound_requests
, having just one of them no longer triggers an issue for some reason.
Also if replacing result_receiver.await.map_err(|_| ())
with this:
result_receiver.await.unwrap();
Ok(())
Then I'm getting following interesting error:
thread 'tests::basic' panicked at library/core/src/panicking.rs:223:5:
panic in a destructor during cleanup
thread caused non-unwinding panic. aborting.
Which might be of interest as well.
Tried again today and the error is slightly different:
tcache_thread_shutdown(): unaligned tcache chunk detected
I guess might be related to side-effects of incremental compilation.
@taiki-e I was able to reduce it to this:
#[test]
fn basic() {
use futures::stream::FuturesUnordered;
use std::future::Future;
use std::pin::Pin;
use std::task::{Context, Poll};
struct BadFuture;
impl Drop for BadFuture {
fn drop(&mut self) {
panic!()
}
}
impl Future for BadFuture {
type Output = ();
fn poll(self: Pin<&mut Self>, _cx: &mut Context<'_>) -> Poll<Self::Output> {
Poll::Pending
}
}
FuturesUnordered::default().push(BadFuture);
}
Note that for some reason it only segfaults in a test, not when used in fn main
.
Thanks for the repro. If the problem is that we are not properly handling buggy futures that cause panic on drop, then all we may really be able to do is leak the rest on panic or convert panic to abort.
I would have expected panic to be propagated further somehow, but I don't know the underlying reason why this is happening
Originally reported as https://github.com/tokio-rs/tokio/issues/6452, but I think this might be a
futures
problem actually.I created a (non-minimal unfortunately) reproduction branch where last commit is showing an issue: https://github.com/subspace/subspace/tree/futures-malloc_consolidate-reproduction
On Linux it looks like this:
Here is a backtrace I collected originally:
The change in last commit is actually incorrect and causes panic, specifically this code is not allowed to block in single-threaded tokio runtime:
I expected to see a panic, but getting memory issues instead.
As shown in https://github.com/tokio-rs/tokio/issues/6452#issuecomment-2031837214 the likely cause is
futures
crate,FuturesUnordered
to be specific.