GNOME Bugzilla – Bug 726765
Ensure that queued events have a ClutterStage associated to them
Last modified: 2021-06-10 11:31:42 UTC
Hi, There were some recent changes in clutter-event-win32.c (commit e70a0109, "Avoid needless event copies when queueing from a backend to a stage"), which causes programs to crash when using the Win32 backend. Specifically, when a Clutter program is running, and a stage (window) is drawn, whenever the mouse cursor is moved onto the window, the program will crash immediately, due to an access violation (i.e. segfault).
Created attachment 272463 [details] [review] Check event->any.stage before calling _clutter_stage_queue_event() Hi, This is my patch for fixing this, for Windows. Basically event->any.stage needs to be checked whether it is not NULL before calling _clutter_stage_queue_event(), to avoid the access violation and/or critical warnings that the stage is not valid. p.s. I am not sure whether this problem hits other backends, and it seems that the GDK backend is broken on Windows, as loads of: (test-interactive-clutter.exe:2372): Pango-CRITICAL **: pango_font_description_from_string: assertion 'str != NULL' failed (test-interactive-clutter.exe:2372): Pango-CRITICAL **: pango_context_set_font_description: assertion 'desc != NULL' failed is being thrown on programs with text being drawn on the stage, which I will try to investigate through another bug report :| With blessings, thank you!
Review of attachment 272463 [details] [review]: it looks okay, but we should really check why we're getting an event translated without any stage attached to it. we either need ensure that the stage is always assigned, or never push the event without the stage. looking at the win32 event code, it's a bit of a mess. I can try disentangling it, but I won't really be able to test it — except maybe under Wine.
Hello Emmanuele, > but we should really check why we're getting an event translated > without any stage attached to it. I think so too, I will also try to take a look at it as well, but it would have to be a week later, as I will be away, meaning that I wouldn't be able to test it until then. Oh, I have pushed the patch as 4c204a4f co clutter-1.18, but due to the nature of this issue, I think it might be better that we keep this bug open. Thanks though for the reviews and feedback. With blessings.
Created attachment 274642 [details] [review] Fix and Cleanup Win32 Event Handling Hi, This is my take for fixing the issue where the ClutterStage is not attached to the queued events at times. It seems that during a WM_MOUSEMOVE, an additional event was created when the mouse cursor moves onto the stage, but did not attach a stage to it. The way I tried to fix this (and the programs seem to run fine) is by creating a single event during a WM_MOUSEMOVE depending on whether the cursor was moved onto the stage, and handle that event accordingly. Since the event handling code also needed for some cleanup, I also attempted to clean it a bit (by consolidating variable declarations, the attachment of the stage to the event, and queuing the event), and also updated the code styling to be more like what is being used in GLib et al. With blessings, thank you!
Hello, pinging here... Would like to know whether this patch is okay? Thanks, with blessings!
Hi, Any further issues about the second patch?
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of clutter, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a ticket at https://gitlab.gnome.org/GNOME/clutter/-/issues/ Thank you for your understanding and your help.