Repository navigation
Unregister fds in kill - #245
Conversation
|
I'm not really familiar with this part of calloop, but It would be good to get one or more unit tests for the behavior here. |
|
Looks like a reproduction can be as simple as: use std::os::unix::net::UnixStream;
use std::rc::Rc;
fn main() {
let event_loop = calloop::EventLoop::<()>::try_new().unwrap();
let handle = event_loop.handle();
let socket = Rc::new(UnixStream::pair().unwrap().0);
handle.adapt_io(socket.clone()).unwrap();
handle.adapt_io(socket).unwrap();
};This seems to panic on the second |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #245 +/- ##
==========================================
+ Coverage 85.47% 85.99% +0.51%
==========================================
Files 14 16 +2
Lines 1818 1949 +131
==========================================
+ Hits 1554 1676 +122
- Misses 264 273 +9
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Rebased and added 2 unit tests. Now I understand this and have tests to reproduce this, I'm pretty sure this is correct. Though it looks like |
On FreeBSD, if we don't call
unregister, a stale source is left behind in polling's kqueue implementation.It becomes impossible to reuse that fd number, resulting in a crash for niri because of an
AlreadyExistserror (niri-wm/niri#4016).This change tracks dispatcher registration in
registerandreregister, and subsequently doesunregister(if necessary) whenkillis called.I've only tested this on FreeBSD with niri.