-
Notifications
You must be signed in to change notification settings - Fork 342
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
Spawned task is stuck during flushing in File.drop() #900
Comments
Collected the backtraces of the stuck process:
|
Sidenote: there is a third alternative to dropping unwritten data and flushing it in a blocking way. It's possible to spawn a new task that will do the flushing sometime later. If user did not care to flush the file, it can be postponed. |
Maybe this can be reproduced more reliably and converted into a test? Is it possible to cause |
We likely need to stop flushing automatically in the drop impl, and add to the docs that flushing is required to be manual. This is what |
It's possible to remove |
Here is a way to create unflushed file: Line 411 in 11196c8
I'll try to use it and see what happens. |
This code does not fail on Linux:
But maybe because write operation never actually blocks. |
Reproduced on Alpine linux under qemu, running on top of qcow2 disk backed by HDD. Dumped the core, copied to the host system and loaded it in gdb. On the host system same binary successfully writes the file by the way. So it is reproducible both with kqueue and epoll, on NetBSD and Alpine Linux running in KVM and on real Android. Stacktraces with epoll, produced on Debian from binary and core file downloaded from Alpine
|
Can you perhaps try replacing https://docs.rs/async-fs/1.5.0/async_fs/struct.File.html Let's if there's a problem in the async file implementtion or somewhere else. |
With |
|
But Also, with |
On Debian, the file is written even with |
Probably related problem, |
I had a case of this today. It occurred in a VM running under Virtualbox, running Rocky Linux 8. The application I was testing is quite complex, the relevant bit has async tasks which are reading from TCP sockets, processing what they read, and writing the results to a file. The VM was configured with two CPUs, so there were 2 async runtime threads. Each time I observed it, both runtime threads were stuck trying to drop Adding a There definitely needs to be some documentation about this - I wasted a huge amount of time trying to debug this before stumbling across this ticket. |
I think the problem is in In other words, just |
This makes perfect sense. You would need to have at least N+1 runtime threads in order to be able to drop N One thing I do not understand though: when I configure my VM with 1 CPU, or instruct async_std to create one runtime thread via ASYNC_GLOBAL_EXECUTOR_THREADS, the reproduction program at the top of this ticket does not trigger a hanging for me. |
I made a fix #1033 but have not really tested it. |
Original issue is deltachat/deltachat-core-rust#2032
I have prepared a minimal example demonstrating the bug, which depends only on
async-std
1.6.5.An example which you can unpack and run with
cargo run
: filedrop.tar.gzThe source code for reference:
I built this example in the following configuration:
When I execute
cargo run
, the program printsbefore drop
and gets stuck. Apparently the problem is that despite what comment says, executor does not handle blocking operation in Drop correctly:async-std/src/fs/file.rs
Line 314 in 11196c8
After waiting a minute and terminating the program, the file
foo.txt
is created, but is empty.When I uncomment the line
file.flush().await.unwrap();
, the program printsand exits.
On my Linux machine this works correctly. It is not a QEMU bug, as the same problem is experienced on some Android phones, see original issue deltachat/deltachat-core-rust#2032
The text was updated successfully, but these errors were encountered: