Subject: bug#15801: 24.3.50; bar scrolling freezes gtk emacs

From: Jarek Czekalski <[email-masked]>
Date: Thu, 05 Dec 2013 18:08:10 +0100

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"

Jarek