notify-rs
kqueue 1.1.1 causing panics with macos_kqueue
kqueue 1.1.1 is causing panics when it gets an event for something that it is not actually watching (this can happen if you watch a directory but unwatch a subdirectory).
Forcing kqueue back to 1.0.8 fixes the issue.
ERROR: [panic /Users/nikita/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/kqueue-1.1.1/src/lib.rs:670] called `Option::unwrap()` on a `None` value
at: godot_core::private::set_gdext_hook::{{closure}} (/Users/nikita/.cargo/git/checkouts/gdext-067f4b88e7bd088f/a752851/godot-core/src/private.rs:300)
[panic backtrace]
...
11: core::option::unwrap_failed
at /rustc/4d91de4e48198da2e33413efdcd9cd2cc0c46688/library/core/src/option.rs:2015:5
12: core::option::Option<T>::unwrap
at /Users/nikita/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/src/rust/library/core/src/option.rs:978:21
13: kqueue::Event::new
at /Users/nikita/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/kqueue-1.1.1/src/lib.rs:661:42
14: kqueue::get_event
at /Users/nikita/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/kqueue-1.1.1/src/lib.rs:602:19
15: kqueue::Watcher::poll
at /Users/nikita/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/kqueue-1.1.1/src/lib.rs:513:21
16: notify::kqueue::EventLoop::handle_kqueue
at /Users/nikita/.cargo/git/checkouts/notify-abad3ad1d5b14b99/83e1e04/notify/src/kqueue.rs:155:33
17: notify::kqueue::EventLoop::handle_event
at /Users/nikita/.cargo/git/checkouts/notify-abad3ad1d5b14b99/83e1e04/notify/src/kqueue.rs:128:17
18: notify::kqueue::EventLoop::event_loop_thread
at /Users/nikita/.cargo/git/checkouts/notify-abad3ad1d5b14b99/83e1e04/notify/src/kqueue.rs:109:17
19: notify::kqueue::EventLoop::run::{{closure}}
at /Users/nikita/.cargo/git/checkouts/notify-abad3ad1d5b14b99/83e1e04/notify/src/kqueue.rs:91:23
20: std::sys::backtrace::__rust_begin_short_backtrace
at /Users/nikita/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/src/rust/library/std/src/sys/backtrace.rs:152:18
21: std::thread::Builder::spawn_unchecked_::{{closure}}::{{closure}}
at /Users/nikita/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/src/rust/library/std/src/thread/mod.rs:564:17
22: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
at /Users/nikita/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/src/rust/library/core/src/panic/unwind_safe.rs:272:9
23: std::panicking::try::do_call
at /Users/nikita/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/src/rust/library/std/src/panicking.rs:584:40
24: ___rust_try
25: std::panicking::try
at /Users/nikita/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/src/rust/library/std/src/panicking.rs:547:19
26: std::panic::catch_unwind
at /Users/nikita/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/src/rust/library/std/src/panic.rs:358:14
27: std::thread::Builder::spawn_unchecked_::{{closure}}
at /Users/nikita/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/src/rust/library/std/src/thread/mod.rs:562:30
28: core::ops::function::FnOnce::call_once{{vtable.shim}}
at /Users/nikita/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5
29: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
at /rustc/4d91de4e48198da2e33413efdcd9cd2cc0c46688/library/alloc/src/boxed.rs:1993:9
30: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
at /rustc/4d91de4e48198da2e33413efdcd9cd2cc0c46688/library/alloc/src/boxed.rs:1993:9
31: std::sys::pal::unix::thread::Thread::new::thread_start
at /rustc/4d91de4e48198da2e33413efdcd9cd2cc0c46688/library/std/src/sys/pal/unix/thread.rs:106:17
32: __pthread_deallocate
Shit, this is 100% me. I'm surprised it made it past CI, since it appears that the tests should've caught this double-close bug.
The fast solution is to rollback to 1.0.8, I can write a patch and ship it tomorrow when I have some more time.
@nikitalita Hey, out of curiosity, are you running a notify that includes https://github.com/notify-rs/notify/commit/c11e8315ba00cea004999b0dd9ac178732861512
I had thought I knew what the issue was, but upon further inspection it's not what I thought. If you have a simple repro case, I'd super appreciate it.
fyi this is a more general kqueue issue, not specific to macOS. I'm seeing it under FreeBSD as well, but on a slightly earlier line with the panic tracing back to index.crates.io-1949cf8c6b5b557f/kqueue-1.1.1/src/lib.rs:661:86:
https://gitlab.com/rust-kqueue/rust-kqueue/-/blob/main/src/lib.rs?ref_type=heads#L661 which is
EventFilter::EVFILT_VNODE => find_file_ident(watcher, ev.ident as RawFd).unwrap(),
(I first went to the kqueue gitlab repo, but issues are disabled there.)
Hey @mqudsi, I'm not sure what you mean that issues are disabled there. I have them enabled with the maximum visibility available. Others have filed issues in the past.
re: the problem you're talking about, did you see this with a notify that includes https://github.com/notify-rs/notify/commit/c11e8315ba00cea004999b0dd9ac178732861512 ? Running a prior version could cause an issue that would crash in the same location.
I came across a similar crash, https://github.com/watchexec/watchexec/issues/967. Is that the same issue?
@silver886 No, that's a different issue. It's reported here: https://gitlab.com/rust-kqueue/rust-kqueue/-/issues/17 It's unfortunately a bit tricky to fix generically without cutting a new major version. I do have it planned to break the API and do a major change so that this wouldn't be a problem, I just don't have the bandwidth rn. I'll try and take a look to see what filters and such are missing on FreeBSD.
It looks like this current issue got fixed from c11e831 according to some user tests: https://github.com/Canop/bacon/issues/388