I've found one of my projects (www.chimara-if.org) to be broken in the 3.8 series of GTK on the Quartz backend. Admittedly, this project is a heavy user of gdk_threads_enter()/_leave(), and I really should port it so that GTK calls are on the main thread, but I can't invest that time in it just now. And though GDK threads are deprecated, they should still work until GTK 4, right?

Debugging shows that the program crashes early on, at various places, somewhere during drawing a GtkTextView. I've dealt with this kind of thing before and usually it meant that I forgot to acquire the GDK lock before calling a GTK function. Indeed, both the main thread and my thread were in the middle of calling GTK functions when the program crashed, suggesting a race condition. Only, my thread did hold the GDK lock, so I thought maybe GTK forgot to acquire it somewhere.

By bisection I determined that the regression started at some point during the introduction of frame clocks in the 3.7 series. I wondered if the GDK lock was held while running frame clock tick callbacks; it did not seem to be. This patch fixes that. However, it only fixes my crash for one revision of GTK, 449e8c88 (https://git.gnome.org/browse/gtk+/commit/?id=449e8c88565b444d1399a9080bde5141d054bde6), the following commit breaks it again -- which suggests that the race condition is elsewhere entirely and holding the GDK lock during tick callbacks merely prevents it from occurring by chance.

So even though it doesn't solve my problem I thought I would suggest this fix in a bug report, since it seems logical to me. However, I really don't know what repercussions it might have. Can anyone advise me?