GNOME Bugzilla – Bug 137968
Sometimes a GIOFunc on Win32 is called with zero condition
Last modified: 2018-05-24 10:31:07 UTC
Sometimes GLib calls the callback function set with g_io_add_watch() with the condition equalling zero. See the comments added today in bug #132113. This seems to happen only when you are moving one of GIMP's windows while it is talking to a plug-in, so presumably the Win32 code in gmain.c gets confused and calls also the callback for the plug-in's read pipe when it is notified that there is a Windows message waiting. Or something. Anyway, should be trivial to simply make sure that a callback isn't called with a zero condition, but it would be better to find the root cause why it even would want to do it, of course.
The calling of callbacks with zero condition is triggered by the relatively recently added handle_stuff_while_moving_or_resizing() functionality in gdkevents-win32.c. The end result is that g_io_win32_dispatch() gets called when a watched GIOWin32Channel has had some bit set in its revents flag, but the corresponding watches GPollFD's revents hasn't been set. Sometimes the gdk_event_dispatch() function is called recursively. The PeekMessage() calls apparently can cause calls to the window procedure. The calls to PeekMessage(PM_NOREMOVE) in gmain.c and gdkevents-win32.c probabnly should be changed to GetQueueStatus(QS_ALLINPUT) calls instead. as that does less unexpected stuff. Perhaps gdk_event_prepare() and gdk_event_check() should not call PeekMessage() (or GetQueueStatus()) at all. Etc, this whole mess needs to be thoroughly debugged. There are some disturbingly ad-hoc stuff done here, for instance changing the "arbitrary_limit" value in handle_stuff_while_moving_or_resizing() from 1 to some higher value causes hangs when moving top-level windows, ugggh... See discussion in bug #99540, A straightforward fix so that callbacks wouldn't be called with zero condition would be to insert into g_io_win32_dispatch() the same code snippet as is in g_io_win32_check(): if (channel->type != G_IO_WIN32_WINDOWS_MESSAGES) { watch->pollfd.revents = (watch->pollfd.events & channel->revents); } before calling the callback function. But I think that is just fixing the symptom, it would be better to fix whatever causes this to happen. Maybe.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/18.