GNOME Bugzilla – Bug 719883
resuming events not effective, causing a freeze
Last modified: 2018-04-15 00:30:19 UTC
When pausing and resuming events, frame clock idle timer is used. It seems to work on an on/off basis. However inside gdk it transforms into pause/unpause functions, which works on a counter basis: pause increases the counter, unpause - decreases. In a complicated application, full of x11 direct calls, glib and gtk customized loop, I experience a freeze. The last thing I register is pausing events twice and resuming only once. Do you think gtk is safe regarding resuming events? Isn't there any possibility that "resume-events" signal is compressed and instead of double call only a single one is made? To me one possible place could be a clock idle timer, working on a on/off basis. If it is already on (scheduled to resume), it is impossible to turn it on again. This is the way pausing/resuming is fired: gdk_frame_clock_request_phase (clock, GDK_FRAME_CLOCK_PHASE_FLUSH_EVENTS); gdk_frame_clock_request_phase (clock, GDK_FRAME_CLOCK_PHASE_RESUME_EVENTS); But there is also a direct call to _gdk_display_pause_events (display) (from gdk_window_flush_events), which bypasses the timer. Looking forward to your comments!
Created attachment 263706 [details] backtrace of reentry to gdk_window_flush_events
I know when it happens. Inside scroll bar callback (in the app I debug) glib main loop is called. So we have a reentrancy to glib event loop (I guess that's forbidden) which results in reentrancy to gdk_window_flush_events. Then we have what I predicted: 2 clock phases are reduced to a single one and events are never resumed. For me it's logical that one can't call g loop from inside signal handler. Is it stated explicitly somewhere? If that's enough to close the bug, please do. For the curious - attaching a backtrace. This is from gtk 3.8.6 tag, with some debugging modifications.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new