Winit: send_event not waking up event loop on X11

[worktycho]

This is similar behavior to #834 (the event loop not being woken up by event loop proxy) but observed in winit 2.0 as of dbc567984f8ba07448ec2e8ea286a5df5aa38e09. It would appear that the main thread blocks on an epoll call inside mio, and the user events channel does not wake the epoll call.

[murarth]

I'm unable to reproduce this issue using the custom_events example. Do you experience the issue using that example?

[worktycho]

Trying now.

[worktycho]

I don't get it in the example. I'll need to spend some more time trying to reproduce this.

[worktycho]

I am compiling the example with mio 0.6.21 and mio-extras 2.0.6, whilst my code that I'm seeing the bug in is compiling against mio 0.6.19 and mio-extras 2.0.5 which might have something to do with it. The fact that the code that exhibits this issue is running two seperate instances of mio doesn't help to debug this. It appears that send_event is trying to wake up the thread in question. I'll continue trying to track this down tomorrow but its looking less and less like a winit event bug and more something in the underlying libraries the more I stare at it.

[kchibisov]

I feel like you've managed to repro this bug from alacritty https://github.com/jwilm/alacritty/issues/824 . It's quite old, but it was also discovered in alacritty on X11 ( I can't repro it on Wayland ) and we use mio as well.

We also use send_event to send Wakeup's (they trigger redraw in alacritty) and in some rare cases it can freeze. It's quite hard to repro, but we managed to repro this bug with winit's evlp2.

IIRC we spend some time debugging it, but without any useful results (well, if you send something periodically you'll unfreeze your app), playing with polling was also unsuccessful ( I mean in alacritty mio things).

FWIW related code from alacritty is here https://github.com/jwilm/alacritty/blob/9da0c042d4d4ef72b4488424df5c20d14d4e9585/alacritty_terminal/src/event_loop.rs#L264 , so maybe it's similar to what you're doing @worktycho ?

cc @chrisduerr , since we were debugging this thing together in the past.

P.s. There's a chance that I've misread your issue, but anyway...

[worktycho]

@kchibisov I agree it looks like that issue. I have a build I can reliably repo it in in the debugger, but I'm still trying to work out how the wakeup should happen. I raised a new issue rather than the original one because I believe that the behavior in eventloop 2 has a different root cause than the same behavior in eventloop 1. In eventloop 2 I'm seeing the receiving thread halt in a call to epoll rather than xlib.

[worktycho]

If its at all useful, here is the backtrace of the blocked event loop thread:

#0  0x00007ffff6ddcbb7 in epoll_wait (epfd=19, events=0x55555686c8e0, maxevents=32, timeout=-1)
    at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
#1  0x00005555560d07c7 in mio::sys::unix::epoll::Selector::select (self=0x5555568e3d80, evts=0x7fffffff82f8, awakener=..., 
    timeout=...) at mio-0.6.19/src/sys/unix/epoll.rs:72
#2  0x00005555560c4bdb in mio::poll::Poll::poll2 (self=0x5555568e3d80, events=0x7fffffff82f8, timeout=..., interruptible=false)
    at mio-0.6.19/src/poll.rs:1178
#3  0x00005555560c48c5 in mio::poll::Poll::poll1 (self=0x5555568e3d80, events=0x7fffffff82f8, timeout=..., interruptible=false)
    at mio-0.6.19/src/poll.rs:1139
#4  0x00005555560c4157 in mio::poll::Poll::poll (self=0x5555568e3d80, events=0x7fffffff82f8, timeout=...)
    at mio-0.6.19/src/poll.rs:1010
#5  0x0000555555904089 in calloop::loop_logic::EventLoop<Data>::dispatch_events (self=0x7fffffff82e0, timeout=..., 
    data=0x7fffffff7870) at calloop-0.4.4/src/loop_logic.rs:147
#6  0x0000555555904894 in calloop::loop_logic::EventLoop<Data>::dispatch (self=0x7fffffff82e0, timeout=..., data=0x7fffffff7870)
    at calloop-0.4.4/src/loop_logic.rs:189
#7  0x0000555555a60e43 in winit::platform_impl::platform::x11::EventLoop<T>::run_return (self=0x7fffffff82e0, callback=...)
    at winit-ca3d7d433f10f6e2/dbc5679/src/platform_impl/linux/x11/mod.rs:359
#8  0x0000555555a61a8b in winit::platform_impl::platform::x11::EventLoop<T>::run (self=..., callback=...)
    at winit-ca3d7d433f10f6e2/dbc5679/src/platform_impl/linux/x11/mod.rs:388
#9  0x00005555556f71ae in winit::platform_impl::platform::EventLoop<T>::run (self=..., callback=...)
    at winit-ca3d7d433f10f6e2/dbc5679/src/platform_impl/linux/mod.rs:640
#10 0x000055555591f314 in winit::event_loop::EventLoop<T>::run (self=..., event_handler=...)

[worktycho]

Okay, this is looking weird, I can show in the debugger that the awaking fd is being written too. But the epoll that should be waiting on it doesn't trigger.

[Osspial]

I am compiling the example with mio 0.6.21 and mio-extras 2.0.6, whilst my code that I'm seeing the bug in is compiling against mio 0.6.19 and mio-extras 2.0.5 which might have something to do with it.

If updating mio fixes this, it would seem that this is a bug in upstream code. Does running cargo update on the codebase that exhibits this bug fix it there? If so, I'm inclined to close this issue.

[worktycho]

I'm afraid the versions don't appear to have been the problem, as the problem still persists after a cargo update, and the example don't show the problems with the version pinned to the original versions I had in the exhibiting code.

[worktycho]

I think I've tracked down the bug, its not a winit issue, it this case its to do with my response to the event.

[Osspial]

Out of curiosity, what was the issue exactly? It's probably good to document it online, in case somebody stumbles upon this issue when running into a similar problem.

[worktycho]

I was mutating a data structure in response to an event, and and using that data structure to drive the draws. But not explicitly requesting a redraw after performing the mutation. So my view model would be updated, but not what the user actually saw.