GNU bug report logs - #15801
24.3.50; bar scrolling freezes gtk emacs

Previous Next

Full log

Message #71 received at 15801 <at> debbugs.gnu.org (full text, mbox):

From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
To: 15801 <at> debbugs.gnu.org
Subject: bug#15801: 24.3.50; bar scrolling freezes gtk emacs
Date: Wed, 04 Dec 2013 21:28:38 +0100

[Message part 1 (text/plain, inline)]

I have bad news. It's time to think about the call to 
g_main_context_query, because it seems to destroy the fragile workflow 
of gtk. There are timeout triggered events "pause-events" and 
"resume-events". Every mouse movement triggers one pause and one resume. 
In my case finally pause is called twice while resume - once. There goes 
the freeze.

I attach gdb backtraces for you to see what is the code flow to reach 
those pause and resume methods. Breakpoints were set in
_gdk_display_pause_events
_gdk_display_unpause_events

Source codes used are:
gtk 3.8.6
glib 2.36.4
emacs r115317

Now I know why the commit r112892 causes troubles. Because it enables 
the code path in which the code unbalancing gtk is run. Why this code 
may be run safely when events are pending? Maybe because in this case 
polling doesn't change anything, events are pending anyway. But this is 
a guess. What is sure is that you can't take just one gtk method and use 
it out of the context for which it was designed. It causes big troubles, 
for a guy who wants to debug the problem. You never know when it 
strikes. Let's make it safe.

The first thing I would do now is finding the real bugs that were being 
fixed by r112892. Maybe there is another way of fixing them, without 
calling g_main_context_query.

Jarek

[backtrace.txt (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.