Hello. 5 dec 2013 kl. 18:08 skrev Jarek Czekalski : > I founded a way to freeze Emacs without using any syntax, that could be considered incorrect from the glib/gtk point of view. At least nothing incorrect stays in xgselect. > > This is practically whole xg_select function, that still makes Emacs freeze: > > context = g_main_context_default (); > while (g_main_context_iteration(context, 0)); // 0 = no wait > return 1; > > So this makes context_query call free of any charges. I'm sorry for blaming it for the problems. But it's so tempting when you see something theoretically incorrect, to blame it for all the problems. > > I'll try to locate the place in gtk that starts the problem. So far I only know that the commit from gtk 3.7.10 introducing > motion compression is not yet making it freeze. Although that sounded promising. So I'm starting binary search with gtk 3.7.10 being safe, and 3.8.4 failing. I hope to help with fixing it, because gtk 3.8.4 is going to be used in next stable Debian, jessie, which is currently described as testing. > > Motion compression commit: > https://git.gnome.org/browse/gtk+/commit/gdk/gdkwindow.c?id=a69285da08a2a61d5fd817ee8ccb88a6b6deaef6 > > If someone is still listening, please help me gather statistics about this bug. If you have: > 1. libgtk-3 >=3.7.10 > 2. emacs built with gtk3 > Please report through priv whether you reproduce or not. Tell me even if you don't reproduce and send the output of /proc/cpuinfo. Mine is "Intel Celeron 3.2G". My email: jarekczek # poczta.onet.pl. > Remember to make sure which gtk is actually used, for example using "strace emacs -Q 2>&1 | grep libgtk" This whole clock-thing (enable/disable events in Gtk+) is quite new (3.7) , so I'd expect there will be bugs. As I said, I can't reproduce it on Gtk+ 3.8.6. Don't know why cpuinfo is relevant, I would suspect graphics driver more. But Gtk+ bugs the most. Jan D.