The immediate symptom is that hitting causes the application to lock up with the CPU spinning and strace revealing that it is looping being told there are X events to process but them not being processed.
Investigation with a debugger has shown that the problem is that gdkdisplay is not handling the events because _gdk_display_pause_events has been called and has paused event handling.
In turn that has happened because gdkwindow has received a flush-events signal, so gdk_window_flush_events has paused event handling and asked the frame clock to resume when it is ready. The resume-events signal never arrives however and hence event handling remains paused.
Moving up it turns out the the reason gdkframeclockidle.c never sends the resume-events signal is that it is destroyed (because the associated window is closed) before gdk_frame_clock_paint_idle runs and gets a change to resume the events.
I'm attaching a stack trace from the point where the frame clock is destroyed, showing the trace back to the OK button handler in the python code. My environment is:
Gramps 4.1.1 Python 3.4.1 Python GObject 3.14.0 GTK 3.14.6 GLib 1.2.10The question is, am I looking at a bug in GTK here (in that it needs to handle the case where a frame clock is destroyed with a resume still pending) or should that not be possible if GTK is used correctly, in which case there is presumably an error in the way Gramps is using the GTK API that is triggering this?
Tom -- Tom Hughes (tom compton nu) http://compton.nu/
Attachment:
trace
Description: Text document