Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Random panic behaviour in Windows after CTRL+C has been handled #1970

Closed
mgostIH opened this issue Dec 16, 2019 · 3 comments · Fixed by #1978
Closed

Random panic behaviour in Windows after CTRL+C has been handled #1970

mgostIH opened this issue Dec 16, 2019 · 3 comments · Fixed by #1978
Labels
C-bug Category: This is a bug.

Comments

@mgostIH
Copy link

mgostIH commented Dec 16, 2019

Version

tokio = { version = "0.2", features = ["signal", "time", "fs", "rt-core", "io-util"] }

Platform

Windows 7 64 bit

Description

This simple program sometimes causes a panic after it received the CTRL+C signal, happens around 1 out of 5 times.
Based on the output of the program, it seems that the signal future completes successfully without problems, as the println! from line 31 gets executed, but the file isn't being written by the call write_to_file right after it.

This is the code:
https://gist.github.com/mgostIH/5bb82b84c5113caf5e717f81eb0fced4

I expected the code to run deterministically, as sometimes it actually works and perfectly handles the signal.

Instead, sometimes it panics outputting this on RUST_BACKTRACE=full :

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.48s
     Running `target\debug\cli_timer.exe`
Starting to work!
Timer was stopped when we were working
thread 'main' panicked at 'state = Snapshot { is_running: false, is_notified: true, is_released: false, is_complete: false, is_canceled: false, is_join_interested: false, has_join_waker: false, is_final_ref: false }', C:\Users\user\.cargo\registry\src\github.com-1ecc6299db9ec823\tokio-0.2.4\src\task\state.rs:227:9
stack backtrace:
   0:        0x13fa8d8d9 - std::sys_common::backtrace::_print::{{impl}}::fmt
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libstd\sys_common\backtrace.rs:60
   1:        0x13fa9e21b - core::fmt::write
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libcore\fmt\mod.rs:1030
   2:        0x13fa8ac64 - std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libstd\io\mod.rs:1413
   3:        0x13fa90390 - std::panicking::default_hook::{{closure}}
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libstd\panicking.rs:196
   4:        0x13fa8ffba - std::panicking::default_hook
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libstd\panicking.rs:212
   5:        0x13fa90be8 - std::panicking::rust_panic_with_hook
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libstd\panicking.rs:473
   6:        0x13fa90754 - std::panicking::continue_panic_fmt
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libstd\panicking.rs:380
   7:        0x13fa9069f - std::panicking::begin_panic_fmt
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libstd\panicking.rs:335
   8:        0x13fa0c35a - tokio::task::state::State::release_task
                               at C:\Users\user\.cargo\registry\src\github.com-1ecc6299db9ec823\tokio-0.2.4\src\task\state.rs:227
   9:        0x13fa5d2ba - tokio::task::harness::Harness<tokio::runtime::blocking::task::BlockingTask<closure-0>, tokio::runtime::blocking::schedule::NoopSchedule>::drop_task<tokio::runtime::blocking::task::BlockingTask<closure-0>,tokio::runtime::blocking::schedule::NoopSchedule>
                               at C:\Users\user\.cargo\registry\src\github.com-1ecc6299db9ec823\tokio-0.2.4\src\task\harness.rs:158
  10:        0x13fa2a682 - tokio::task::raw::drop_task<tokio::runtime::blocking::task::BlockingTask<closure-0>,tokio::runtime::blocking::schedule::NoopSchedule>
                               at C:\Users\user\.cargo\registry\src\github.com-1ecc6299db9ec823\tokio-0.2.4\src\task\raw.rs:168
  11:        0x13fa2a3e2 - tokio::task::raw::RawTask::drop_task
                               at C:\Users\user\.cargo\registry\src\github.com-1ecc6299db9ec823\tokio-0.2.4\src\task\raw.rs:121
  12:        0x13fa0d756 - tokio::task::{{impl}}::drop<tokio::runtime::blocking::schedule::NoopSchedule>
                               at C:\Users\user\.cargo\registry\src\github.com-1ecc6299db9ec823\tokio-0.2.4\src\task\mod.rs:393
  13:        0x13fa17c13 - core::ptr::real_drop_in_place<tokio::task::Task<tokio::runtime::blocking::schedule::NoopSchedule>>
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\src\libcore\ptr\mod.rs:175
  14:        0x13fa17fb1 - core::ptr::real_drop_in_place<slice<tokio::task::Task<tokio::runtime::blocking::schedule::NoopSchedule>>>
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\src\libcore\ptr\mod.rs:175
  15:        0x13fa12226 - alloc::collections::vec_deque::{{impl}}::drop<tokio::task::Task<tokio::runtime::blocking::schedule::NoopSchedule>>
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\src\liballoc\collections\vec_deque.rs:74
  16:        0x13fa1565f - core::ptr::real_drop_in_place<alloc::collections::vec_deque::VecDeque<tokio::task::Task<tokio::runtime::blocking::schedule::NoopSchedule>>>
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\src\libcore\ptr\mod.rs:175
  17:        0x13fa18ebf - core::ptr::real_drop_in_place<tokio::runtime::blocking::pool::Shared>
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\src\libcore\ptr\mod.rs:175
  18:        0x13fa17ae6 - core::ptr::real_drop_in_place<core::cell::UnsafeCell<tokio::runtime::blocking::pool::Shared>>
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\src\libcore\ptr\mod.rs:175
  19:        0x13fa15f93 - core::ptr::real_drop_in_place<std::sync::mutex::Mutex<tokio::runtime::blocking::pool::Shared>>
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\src\libcore\ptr\mod.rs:175
  20:        0x13fa187af - core::ptr::real_drop_in_place<tokio::runtime::blocking::pool::Inner>
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\src\libcore\ptr\mod.rs:175
  21:        0x13fa45232 - alloc::sync::Arc<tokio::runtime::blocking::pool::Inner>::drop_slow<tokio::runtime::blocking::pool::Inner>
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\src\liballoc\sync.rs:705
  22:        0x13fa46275 - alloc::sync::{{impl}}::drop<tokio::runtime::blocking::pool::Inner>
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\src\liballoc\sync.rs:1227
  23:        0x13f9da133 - core::ptr::real_drop_in_place<alloc::sync::Arc<tokio::runtime::blocking::pool::Inner>>
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\src\libcore\ptr\mod.rs:175
  24:        0x13f9dcc63 - core::ptr::real_drop_in_place<tokio::runtime::blocking::pool::Spawner>
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\src\libcore\ptr\mod.rs:175
  25:        0x13f9dc8f3 - core::ptr::real_drop_in_place<tokio::runtime::blocking::pool::BlockingPool>
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\src\libcore\ptr\mod.rs:175
  26:        0x13f9da703 - core::ptr::real_drop_in_place<tokio::runtime::Runtime>
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\src\libcore\ptr\mod.rs:175
  27:        0x13f9e93a2 - cli_timer::main
                               at C:\Users\user\Desktop\Coding\Rust\cli_timer\src\main.rs:15
  28:        0x13f9dcd60 - std::rt::lang_start::{{closure}}<()>
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\src\libstd\rt.rs:64
  29:        0x13fa90597 - std::panicking::try::do_call<closure-0,i32>
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libstd\panicking.rs:292
  30:        0x13fa93c52 - panic_unwind::__rust_maybe_catch_panic
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libpanic_unwind\lib.rs:80
  31:        0x13fa90e12 - std::rt::lang_start_internal
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\/src\libstd\rt.rs:48
  32:        0x13f9dcd3b - std::rt::lang_start<()>
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734\src\libstd\rt.rs:64
  33:        0x13f9e94e0 - main
  34:        0x13faa1454 - __scrt_common_main_seh
                               at d:\agent\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
  35:         0x76e059cd - BaseThreadInitThunk
  36:         0x76f6383d - RtlUserThreadStart
error: process didn't exit successfully: `target\debug\cli_timer.exe` (exit code: `101)```
@hawkw
Copy link
Member

hawkw commented Dec 16, 2019

This seems like it could be the same issue as #1946?

@mgostIH
Copy link
Author

mgostIH commented Dec 16, 2019 •
edited
Loading

Oh, this happened with the single threaded runtime, forgot to tell.
Hope that my traces are of some help if it's an issue that targets all OSes!
EDIT: This error happened even when I wasn't spawning task but instead just awaited on the write_to_file calls

@carllerche carllerche added the C-bug Category: This is a bug. label Dec 17, 2019
@carllerche
Copy link
Member

Thanks for the repro. I am able to reproduce but only w/ the threaded runtime and only on windows.

carllerche added a commit that referenced this issue Dec 17, 2019
@carllerche
rt: fix blocking pool shutdown logic
8620de6 
The blocking task queue was not explicitly drained as part of the
blocking pool shutdown logic. It was originally assumed that the
contents of the queue would be dropped when the blocking pool structure
is dropped. However, tasks must be explictly shutdown, so we must drain
the queue can call `shutdown` on each task.

Fixes #1970, #1946
This was referenced Dec 17, 2019
Merged
Closed
carllerche added a commit that referenced this issue Dec 18, 2019
@carllerche
rt: fix blocking pool shutdown logic (#1978)
83cd754 
The blocking task queue was not explicitly drained as part of the
blocking pool shutdown logic. It was originally assumed that the
contents of the queue would be dropped when the blocking pool structure
is dropped. However, tasks must be explicitly shutdown, so we must drain
the queue can call `shutdown` on each task.

Fixes #1970, #1946
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-bug Category: This is a bug.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

rt: fix blocking pool shutdown logic tokio-rs/tokio
3 participants
@carllerche @hawkw @mgostIH