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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15801 in the body.
You can then email your comments to 15801 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; bar scrolling freezes gtk emacs
Date: Mon, 04 Nov 2013 19:42:29 +0100

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

I crash Emacs built with GTK on Debian Jessie (unstable),
by performing massive scrolling using mouse and the
vertical scroll bar. Messages buffer may be used to that
or the title screen. After several movements with left
button down the scroll bar stops reacting, Emacs as well.

As I was afraid it would be difficult to reproduce
I decided to debug it. What I found out is that
sometimes wait_reading_process_output does not return
for really long time and this causes the freeze.
On the other hand the loop (inside wait_reading_process_output)
works all the time.
XTread_socket from xterm.c also is working, but not properly.
See the comment from the patch (attached):

+       // Sometimes gtk_events_pending is true, but gdk_event_handler
+       // receives nothing and does not increase the count.
+       // If we ignore these pending events, then we lock up,
+       // for example with continuos movements of vertical scroll bar.
+       if (!count) count = 1;

I don't think it's the correct patch. Rather investigation is required,
why gdk_event_handler is not increasing the count.
But I don't feel enough confident with gtk, gdk and Emacs code.
A bit tired also. Anyway I offer further help with solving
this issue, because I can easily reproduce it.

My glib is 2.36.4, libgtk-3-0: 3.8.4-1.

Revisions on which I confirmed the freeze: r113450, r114178, r114884.

Somehow htmlfontify entered the patch file, but I didn't remove
it manually.


In GNU Emacs 24.3.50.5 (i686-pc-linux-gnu, GTK+ Version 3.8.4)
 of 2013-11-04 on jcdeb
Bzr revision: 114884 rgm <at> gnu.org-20131031213910-3509l9e973ne3zy1
Windowing system distributor `The X.Org Foundation', version 11.0.11204000
System Description:    Debian GNU/Linux testing (jessie)

Important settings:
  value of $LC_ALL: en_US
  value of $LANG: pl_PL
  locale-coding-system: iso-latin-1-unix
  default enable-multibyte-characters: t

Major mode: Outline

Minor modes in effect:
  global-whitespace-mode: t
  global-hl-line-mode: t
  recentf-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-h C-h r <help-echo> <down-mouse-2> <mouse-1> C-s
p a t c h C-s C-s <help-echo> <help-echo> <help-echo>
<tool-bar> <Back in history> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <tool-bar> <Back
in history> <help-echo> <help-echo> C-s p a t c h <help-echo>
<down-mouse-2> <mouse-1> <next> <C-down> <C-down> <C-down>
<C-down> <C-down> <C-down> <C-down> <C-down> <C-down>
<next> <next> <prior> <prior> <prior> <prior> <next>
<next> <next> <prior> <prior> C-x C-f <up> <backspace>
<backspace> <backspace> <backspace> C-g C-x C-f <up>
C-x C-f <up> <C-backspace> <C-backspace> <C-backspace>
e r t c / <backspace> <backspace> <backspace> <backspace>
t c / <tab> <tab> <f6> <f6> <down> <down> <down> <down>
<down> <down> <down> <down> <down> <down> <down> <up>
<up> <next> <down> <up> <prior> <up> <up> <up> <up>
<up> <up> <up> <up> <up> <tab> <right> <right> <return>
M-s o d i f f <return> <help-echo> <down-mouse-2> <mouse-1>
<help-echo> <up> <up> C-SPC <end> M-w <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> M-x r e p o <tab> r <tab> <return>

Recent messages:
Loading grep...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark saved where search started [2 times]
Quit
completing-read-default: Command attempted to use minibuffer while in 
minibuffer
Making completion list...
indent-relative: Buffer is read-only: #<buffer *Completions*>
Searched 1 buffer; 4 matches for `diff'
Mark set
Making completion list...

Load-path shadows:
/usr/share/emacs/site-lisp/auto-autoloads hides 
/usr/local/share/emacs/site-lisp/auto-autoloads
/usr/share/emacs/site-lisp/ssl hides /usr/local/share/emacs/site-lisp/ssl
/usr/share/emacs/site-lisp/images hides 
/usr/local/share/emacs/site-lisp/images
/usr/share/emacs/site-lisp/font hides /usr/local/share/emacs/site-lisp/font
/usr/share/emacs/site-lisp/devices hides 
/usr/local/share/emacs/site-lisp/devices
/usr/share/emacs/site-lisp/url-hotlist hides 
/usr/local/share/emacs/site-lisp/url-hotlist
/usr/share/emacs/site-lisp/css hides /usr/local/share/emacs/site-lisp/css
/usr/share/emacs/site-lisp/docomp hides 
/usr/local/share/emacs/site-lisp/docomp
/usr/share/emacs/site-lisp/custom-load hides 
/usr/local/share/emacs/site-lisp/custom-load
/usr/share/emacs/site-lisp/w3 hides /usr/local/share/emacs/site-lisp/w3
/usr/share/emacs/site-lisp/w3-xemac hides 
/usr/local/share/emacs/site-lisp/w3-xemac
/usr/share/emacs/site-lisp/w3-widget hides 
/usr/local/share/emacs/site-lisp/w3-widget
/usr/share/emacs/site-lisp/w3-vars hides 
/usr/local/share/emacs/site-lisp/w3-vars
/usr/share/emacs/site-lisp/w3-toolbar hides 
/usr/local/share/emacs/site-lisp/w3-toolbar
/usr/share/emacs/site-lisp/w3-style hides 
/usr/local/share/emacs/site-lisp/w3-style
/usr/share/emacs/site-lisp/w3-speak hides 
/usr/local/share/emacs/site-lisp/w3-speak
/usr/share/emacs/site-lisp/w3-speak-table hides 
/usr/local/share/emacs/site-lisp/w3-speak-table
/usr/share/emacs/site-lisp/w3-props hides 
/usr/local/share/emacs/site-lisp/w3-props
/usr/share/emacs/site-lisp/w3-print hides 
/usr/local/share/emacs/site-lisp/w3-print
/usr/share/emacs/site-lisp/w3-parse hides 
/usr/local/share/emacs/site-lisp/w3-parse
/usr/share/emacs/site-lisp/w3-mouse hides 
/usr/local/share/emacs/site-lisp/w3-mouse
/usr/share/emacs/site-lisp/w3-menu hides 
/usr/local/share/emacs/site-lisp/w3-menu
/usr/share/emacs/site-lisp/w3-keymap hides 
/usr/local/share/emacs/site-lisp/w3-keymap
/usr/share/emacs/site-lisp/w3-java hides 
/usr/local/share/emacs/site-lisp/w3-java
/usr/share/emacs/site-lisp/w3-imap hides 
/usr/local/share/emacs/site-lisp/w3-imap
/usr/share/emacs/site-lisp/w3-hotindex hides 
/usr/local/share/emacs/site-lisp/w3-hotindex
/usr/share/emacs/site-lisp/w3-hot hides 
/usr/local/share/emacs/site-lisp/w3-hot
/usr/share/emacs/site-lisp/w3-forms hides 
/usr/local/share/emacs/site-lisp/w3-forms
/usr/share/emacs/site-lisp/w3-fast-parse hides 
/usr/local/share/emacs/site-lisp/w3-fast-parse
/usr/share/emacs/site-lisp/w3-emulate hides 
/usr/local/share/emacs/site-lisp/w3-emulate
/usr/share/emacs/site-lisp/w3-emacs hides 
/usr/local/share/emacs/site-lisp/w3-emacs
/usr/share/emacs/site-lisp/w3-display hides 
/usr/local/share/emacs/site-lisp/w3-display
/usr/share/emacs/site-lisp/w3-dired hides 
/usr/local/share/emacs/site-lisp/w3-dired
/usr/share/emacs/site-lisp/w3-cus hides 
/usr/local/share/emacs/site-lisp/w3-cus
/usr/share/emacs/site-lisp/w3-compat hides 
/usr/local/share/emacs/site-lisp/w3-compat
/usr/share/emacs/site-lisp/w3-cfg hides 
/usr/local/share/emacs/site-lisp/w3-cfg
/usr/share/emacs/site-lisp/w3-auto hides 
/usr/local/share/emacs/site-lisp/w3-auto
/usr/share/emacs/site-lisp/cmake-mode hides 
/usr/local/share/emacs/site-lisp/cmake-data/cmake-mode
/usr/local/share/emacs/site-lisp/flim/md4 hides 
/usr/local/share/emacs/24.3.50/lisp/md4
/usr/local/share/emacs/site-lisp/flim/hex-util hides 
/usr/local/share/emacs/24.3.50/lisp/hex-util
/usr/local/share/emacs/site-lisp/dictionaries-common/ispell hides 
/usr/local/share/emacs/24.3.50/lisp/textmodes/ispell
/usr/local/share/emacs/site-lisp/dictionaries-common/flyspell hides 
/usr/local/share/emacs/24.3.50/lisp/textmodes/flyspell
/usr/local/share/emacs/site-lisp/flim/sasl-digest hides 
/usr/local/share/emacs/24.3.50/lisp/net/sasl-digest
/usr/local/share/emacs/site-lisp/flim/sasl-ntlm hides 
/usr/local/share/emacs/24.3.50/lisp/net/sasl-ntlm
/usr/local/share/emacs/site-lisp/flim/sasl hides 
/usr/local/share/emacs/24.3.50/lisp/net/sasl
/usr/local/share/emacs/site-lisp/flim/sasl-cram hides 
/usr/local/share/emacs/24.3.50/lisp/net/sasl-cram
/usr/local/share/emacs/site-lisp/flim/ntlm hides 
/usr/local/share/emacs/24.3.50/lisp/net/ntlm
/usr/local/share/emacs/site-lisp/flim/hmac-md5 hides 
/usr/local/share/emacs/24.3.50/lisp/net/hmac-md5
/usr/local/share/emacs/site-lisp/flim/hmac-def hides 
/usr/local/share/emacs/24.3.50/lisp/net/hmac-def

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils vc-bzr noutline outline misearch multi-isearch
jka-compr info disp-table grep compile comint ansi-color ring whitespace
hl-line cus-start cus-load yasnippet derived easy-mmode edmacro kmacro
help-mode folding-isearch folding cl-macs gv advice help-fns bookmark pp
recentf tree-widget wid-edit easymenu cl cl-loaddefs cl-lib server
time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

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

Message #8 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: 15801: commit identified
Date: Tue, 05 Nov 2013 13:57:01 +0100

I isolated the commit that causes the problem on my machine:

revno: 112859
committer: Paul Eggert <>
branch nick: trunk
timestamp: Wed 2013-06-05 10:04:13 -0700
message:
  Chain glib's SIGCHLD handler from Emacs's (Bug#14474).

  * process.c (dummy_handler): New function.
  (lib_child_handler): New static var.
  (handle_child_signal): Invoke it.
  (catch_child_signal): If a library has set up a signal handler,
  save it into lib_child_handler.
  (init_process_emacs): If using glib and not on Windows, tickle glib's
  child-handling code so that it initializes its private SIGCHLD handler.
  * syssignal.h (SA_SIGINFO): Default to 0.
  * xterm.c (x_term_init): Remove D-bus hack that I installed on May
  31; it should no longer be needed now.

I guess the next step would be isolating the single change.

Jarek

Message #11 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: it's a different revision, 112892
Date: Wed, 06 Nov 2013 20:48:29 +0100

First of all I apologize for giving the wrong revision number in my 
previous report.

When I tried to isolate the piece of code that introduces problems, I 
finally gave up. This all revision may be applied and all works. So I 
did more binary search and finally I'm sure the one below is the right 
revision.

------------------------------------------------------------
revno: 112892
committer: Jan D. <jan.h.d <at> swipnet.se>
branch nick: trunk
timestamp: Sat 2013-06-08 10:48:52 +0200
message:
  * xgselect.c (xg_select): Remove call to window_system_available
  and g_main_context_pending at the top, so Gdk events (i.e. file
  notify) are processed when Emacs is started with -nw.

It's quite short:

=== modified file 'src/xgselect.c'
@@ -44,9 +44,13 @@

-  if (! (window_system_available (NULL)
-     && g_main_context_pending (context = g_main_context_default ())))
-    return pselect (fds_lim, rfds, wfds, efds, timeout, sigmask);
+  /* Do not try to optimize with an initial check with 
g_main_context_pending
+     and a call to pselect if it returns false.  If Gdk has a timeout 
for 0.01
+     second, and Emacs has a timeout for 1 second, 
g_main_context_pending will
+     return false, but the timeout will be 1 second, thus missing the gdk
+     timeout with a lot.  */
+
+  context = g_main_context_default ();

When I apply the code removed in this revision to the current trunk, I 
have a relief. No more freezing, as well as with my first fix that also 
works.

Jarek

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Cc: 15801 <at> debbugs.gnu.org
Subject: Re: bug#15801: it's a different revision, 112892
Date: Thu, 21 Nov 2013 07:00:49 +0100

Hello.

6 nov 2013 kl. 20:48 skrev Jarek Czekalski <jarekczek <at> poczta.onet.pl>:

> First of all I apologize for giving the wrong revision number in my previous report.
> 
> When I tried to isolate the piece of code that introduces problems, I finally gave up. This all revision may be applied and all works. So I did more binary search and finally I'm sure the one below is the right revision.

It seems like Emacs stops receiving SIGIO.  If it is blocked or if Gtk+ stole the signal handler I don't know yet.

	Jan D.

> 
> ------------------------------------------------------------
> revno: 112892
> committer: Jan D. <jan.h.d <at> swipnet.se>
> branch nick: trunk
> timestamp: Sat 2013-06-08 10:48:52 +0200
> message:
>  * xgselect.c (xg_select): Remove call to window_system_available
>  and g_main_context_pending at the top, so Gdk events (i.e. file
>  notify) are processed when Emacs is started with -nw.
> 
> It's quite short:
> 
> === modified file 'src/xgselect.c'
> @@ -44,9 +44,13 @@
> 
> -  if (! (window_system_available (NULL)
> -     && g_main_context_pending (context = g_main_context_default ())))
> -    return pselect (fds_lim, rfds, wfds, efds, timeout, sigmask);
> +  /* Do not try to optimize with an initial check with g_main_context_pending
> +     and a call to pselect if it returns false.  If Gdk has a timeout for 0.01
> +     second, and Emacs has a timeout for 1 second, g_main_context_pending will
> +     return false, but the timeout will be 1 second, thus missing the gdk
> +     timeout with a lot.  */
> +
> +  context = g_main_context_default ();
> 
> When I apply the code removed in this revision to the current trunk, I have a relief. No more freezing, as well as with my first fix that also works.
> 
> Jarek
> 
> 

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

From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#15801: 24.3.50; bar scrolling freezes gtk emacs
Date: Thu, 21 Nov 2013 08:25:15 +0100

W dniu 2013-11-21 07:00, Jan Djärv pisze:
> It seems like Emacs stops receiving SIGIO.  If it is blocked or if Gtk+ stole the signal handler I don't know yet.

Sounds interesting, waiting for more info. I will be glad to learn more 
about signals. This is what I read on 
http://unixhelp.ed.ac.uk/CGI/man-cgi?signal+7, maybe it will be relevant:

       If more than one of the
       threads has the signal unblocked, then the kernel chooses an 
arbitrary
       thread to which to deliver the signal.

There are several threads in action (some belonging to gtk), so this 
tells me Emacs cannot be sure to receive any kernel signal. Gtk uses the 
term signal for a different thing, it makes googling difficult.

Jarek

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 15801 <at> debbugs.gnu.org
Subject: Re: bug#15801: 24.3.50; bar scrolling freezes gtk emacs
Date: Sat, 30 Nov 2013 12:41:27 +0100

Hello.

21 nov 2013 kl. 08:25 skrev Jarek Czekalski <jarekczek <at> poczta.onet.pl>:

> W dniu 2013-11-21 07:00, Jan Djärv pisze:
>> It seems like Emacs stops receiving SIGIO.  If it is blocked or if Gtk+ stole the signal handler I don't know yet.
> 
> Sounds interesting, waiting for more info. I will be glad to learn more about signals. This is what I read on http://unixhelp.ed.ac.uk/CGI/man-cgi?signal+7, maybe it will be relevant:
> 
>       If more than one of the
>       threads has the signal unblocked, then the kernel chooses an arbitrary
>       thread to which to deliver the signal.
> 
> There are several threads in action (some belonging to gtk), so this tells me Emacs cannot be sure to receive any kernel signal. Gtk uses the term signal for a different thing, it makes googling difficult.

Actually the signal handling is sane.  It is somthing else.
In xdisp.c, redisplay_internal there is a path that turns off SIGIO and never turn it on again.
I.e.:

enter redisplay_internal
unrequest_sigio() /* Two paths to do this in the code */
goto retry /* Many places */
goto end_of_redisplay /* One place */

When this path in the code is taken, SIGIO is off (blocked) and never turned on again, and Emacs freezes.

Cc:ing Eli.  The obvious fix would be to request_sigio before exit.  Is there any side effects to this?

This is very hard to reproduce.  I have to scroll like mad on a slow computer to see it.  On a faster computer I can't reproduce it.  I guess it has to do something with the time redisplay takes.

	Jan D.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 15801 <at> debbugs.gnu.org, jarekczek <at> poczta.onet.pl
Subject: Re: bug#15801: 24.3.50; bar scrolling freezes gtk emacs
Date: Sat, 30 Nov 2013 13:54:36 +0200

> From: Jan Djärv <jan.h.d <at> swipnet.se>
> Date: Sat, 30 Nov 2013 12:41:27 +0100
> Cc: 15801 <at> debbugs.gnu.org,
>  Eli Zaretskii <eliz <at> gnu.org>
> 
> enter redisplay_internal
> unrequest_sigio() /* Two paths to do this in the code */
> goto retry /* Many places */
> goto end_of_redisplay /* One place */
> 
> When this path in the code is taken, SIGIO is off (blocked) and never turned on again, and Emacs freezes.
> 
> Cc:ing Eli.  The obvious fix would be to request_sigio before exit.  Is there any side effects to this?

If you call request_sigio only if interrupts_deferred is non-zero, I
see no adverse side effects.

In any case, code paths that turn off SIGIO and never turn it on again
are obvious bugs.  Thanks for finding this one.

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15801 <at> debbugs.gnu.org, Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Subject: Re: bug#15801: 24.3.50; bar scrolling freezes gtk emacs
Date: Sat, 30 Nov 2013 13:51:11 +0100

Hello.

30 nov 2013 kl. 12:54 skrev Eli Zaretskii <eliz <at> gnu.org>:

>> From: Jan Djärv <jan.h.d <at> swipnet.se>
>> Date: Sat, 30 Nov 2013 12:41:27 +0100
>> Cc: 15801 <at> debbugs.gnu.org,
>> Eli Zaretskii <eliz <at> gnu.org>
>> 
>> enter redisplay_internal
>> unrequest_sigio() /* Two paths to do this in the code */
>> goto retry /* Many places */
>> goto end_of_redisplay /* One place */
>> 
>> When this path in the code is taken, SIGIO is off (blocked) and never turned on again, and Emacs freezes.
>> 
>> Cc:ing Eli.  The obvious fix would be to request_sigio before exit.  Is there any side effects to this?
> 
> If you call request_sigio only if interrupts_deferred is non-zero, I
> see no adverse side effects.
> 
> In any case, code paths that turn off SIGIO and never turn it on again
> are obvious bugs.  Thanks for finding this one.

OK, I checked in a fix.  I can't reproduce the bug with this, but I had a hard time reproducing it anyway.

	Jan D.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 15801 <at> debbugs.gnu.org, jarekczek <at> poczta.onet.pl
Subject: Re: bug#15801: 24.3.50; bar scrolling freezes gtk emacs
Date: Sat, 30 Nov 2013 15:55:14 +0200

> From: Jan Djärv <jan.h.d <at> swipnet.se>
> Date: Sat, 30 Nov 2013 13:51:11 +0100
> Cc: Jarek Czekalski <jarekczek <at> poczta.onet.pl>,
>  15801 <at> debbugs.gnu.org
> 
> >> Cc:ing Eli.  The obvious fix would be to request_sigio before exit.  Is there any side effects to this?
> > 
> > If you call request_sigio only if interrupts_deferred is non-zero, I
> > see no adverse side effects.
> > 
> > In any case, code paths that turn off SIGIO and never turn it on again
> > are obvious bugs.  Thanks for finding this one.
> 
> OK, I checked in a fix.  I can't reproduce the bug with this, but I had a hard time reproducing it anyway.

Thanks, but it looks like you called unrequest_sigio instead of
request_sigio ;-)

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15801 <at> debbugs.gnu.org, Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Subject: Re: bug#15801: 24.3.50; bar scrolling freezes gtk emacs
Date: Sat, 30 Nov 2013 15:05:13 +0100

30 nov 2013 kl. 14:55 skrev Eli Zaretskii <eliz <at> gnu.org>:

> Thanks, but it looks like you called unrequest_sigio instead of
> request_sigio ;-)

Drat!  Fixed.

	Jan D.

Message #35 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: 24.3.50; bar scrolling freezes gtk emacs
Date: Sat, 30 Nov 2013 18:04:05 +0100

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

Jan,

Thank you for the attempt. It must be very difficult to work on it, 
without being able to reproduce as easily as it happens on my side.

The attempt failed. The code you inserted is never reached. Even if I 
make it reachable (reducing the condition to "interrupt_input" or make 
it executed always), still hanging occurs with the same ease.

What you fix is probably introduced a very long time ago (before 
r31171), with copy and paste programming method. This could be more 
readable as part of STOP_POLLING and
RESUME_POLLING macros (or maybe even part of stop_polling?). I prepared 
a patch making it so. This has nothing to do with copyright, the idea is 
yours, so please don't credit me in this case. Anyway I posted an 
assignment 2 weeks ago, maybe it arrived already. This is only code 
rearrangement, without any behavior change, so you may skip it as well.

Further discoveries:
1. Making unrequest_sigio never called does not remove the freeze (in 
one attempt it even appeared sooner)
2. Placing STOP_POLLING (patched, containing unrequest) at the very 
beginning of redisplay_internal seems to make no detectable change
Maybe one of these changes would make it reproducable at your box?

When I was debugging threading issues in Java I used a function 
debugDelay(int n) which simulated computations. This could be inserted 
in various places to make bugs reproducable by anyone. Of course finding 
the right place(s) is truly difficult. Maybe this method could be 
applied here. If we don't have such a helper function, I can write it. 
It must trick the compiler, so it not optimize the fictional loop. But I 
can't help in finding the right place to insert it, because I reproduce 
it in a blink of an eye.

Jarek

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

Message #38 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: 24.3.50; bar scrolling freezes gtk emacs - stdout warning
Date: Sat, 30 Nov 2013 18:10:05 +0100

Warning: don't put much debugging output to stdout, it ceases the freeze 
as well.

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

From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Jan Djärv <jan.h.d <at> swipnet.se>, 15801 <at> debbugs.gnu.org
Subject: Re: bug#15801: 24.3.50; bar scrolling freezes gtk emacs
Date: Sat, 30 Nov 2013 19:11:40 +0100

W dniu 2013-11-30 14:55, Eli Zaretskii pisze:
>>
>>>> Cc:ing Eli.  The obvious fix would be to request_sigio before exit.  Is there any side effects to this?
>>> If you call request_sigio only if interrupts_deferred is non-zero, I
>>> see no adverse side effects.

Well, the old code does not bother checking interrupts_deferred. Is this 
important?

  if (interrupt_input)
    request_sigio ();
  RESUME_POLLING;

Jarek

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Cc: jan.h.d <at> swipnet.se, 15801 <at> debbugs.gnu.org
Subject: Re: bug#15801: 24.3.50; bar scrolling freezes gtk emacs
Date: Sat, 30 Nov 2013 20:38:51 +0200

> Date: Sat, 30 Nov 2013 19:11:40 +0100
> From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
> CC: Jan Djärv <jan.h.d <at> swipnet.se>, 
>  15801 <at> debbugs.gnu.org
> 
> 
> W dniu 2013-11-30 14:55, Eli Zaretskii pisze:
> >>
> >>>> Cc:ing Eli.  The obvious fix would be to request_sigio before exit.  Is there any side effects to this?
> >>> If you call request_sigio only if interrupts_deferred is non-zero, I
> >>> see no adverse side effects.
> 
> Well, the old code does not bother checking interrupts_deferred. Is this 
> important?

Look at what request_sigio does.

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Cc: 15801 <at> debbugs.gnu.org
Subject: Re: bug#15801: 24.3.50; bar scrolling freezes gtk emacs
Date: Sun, 1 Dec 2013 00:16:52 +0100

Hello.

30 nov 2013 kl. 18:04 skrev Jarek Czekalski <jarekczek <at> poczta.onet.pl>:

> Jan,
> 
> Thank you for the attempt. It must be very difficult to work on it, without being able to reproduce as easily as it happens on my side.
> 
> The attempt failed. The code you inserted is never reached.

It is indeed reached.  Maybe not when you encountered the freeze.  I traced the signal mask and (un)request_sigio calls, and everytime I got a freeze, it was because unrequest_sigio had been called but request_sigio had not been called.

You obviously have a different freeze.

> Even if I make it reachable (reducing the condition to "interrupt_input" or make it executed always), still hanging occurs with the same ease.
> 
> What you fix is probably introduced a very long time ago (before r31171), with copy and paste programming method.

This sentence I can't understand

> This could be more readable as part of STOP_POLLING and
> RESUME_POLLING macros (or maybe even part of stop_polling?). I prepared a patch making it so. This has nothing to do with copyright, the idea is yours, so please don't credit me in this case. Anyway I posted an assignment 2 weeks ago, maybe it arrived already. This is only code rearrangement, without any behavior change, so you may skip it as well.

POLLING and SIGIO are two different concepts, it would be very unclear to put SIGIO operations in a POLLING macro.

> 
> Further discoveries:
> 1. Making unrequest_sigio never called does not remove the freeze (in one attempt it even appeared sooner)
> 2. Placing STOP_POLLING (patched, containing unrequest) at the very beginning of redisplay_internal seems to make no detectable change
> Maybe one of these changes would make it reproducable at your box?
> 
> When I was debugging threading issues in Java I used a function debugDelay(int n) which simulated computations. This could be inserted in various places to make bugs reproducable by anyone. Of course finding the right place(s) is truly difficult. Maybe this method could be applied here. If we don't have such a helper function, I can write it. It must trick the compiler, so it not optimize the fictional loop. But I can't help in finding the right place to insert it, because I reproduce it in a blink of an eye.

I guess you have to debug it.

	Jan D.

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Cc: 15801 <at> debbugs.gnu.org
Subject: Re: bug#15801: 24.3.50; bar scrolling freezes gtk emacs
Date: Sun, 1 Dec 2013 12:07:07 +0100

1 dec 2013 kl. 11:43 skrev Jarek Czekalski <jarekczek <at> poczta.onet.pl>:

> 
> W dniu 2013-12-01 10:10, Jan Djärv pisze:
>> That brings back the error that commit fixed.
> 
> Your commit also did some optimizations. If the commit really treated only the case of -nw switch, it would have no influence on scroll bars in gtk.
> 
> If you separate your joined commit (fixing and optimization) into 2 separate commits, I can check which part introduces the problem.

I no longer know what commit you are talking about.  This:

=== modified file 'src/xgselect.c'
@@ -44,9 +44,13 @@

-  if (! (window_system_available (NULL)
-     && g_main_context_pending (context = g_main_context_default ())))
-    return pselect (fds_lim, rfds, wfds, efds, timeout, sigmask);
+  /* Do not try to optimize with an initial check with 
g_main_context_pending
+     and a call to pselect if it returns false.  If Gdk has a timeout 
for 0.01
+     second, and Emacs has a timeout for 1 second, 
g_main_context_pending will
+     return false, but the timeout will be 1 second, thus missing the gdk
+     timeout with a lot.  */
+
+  context = g_main_context_default ();



has absolutely nothing to do with -nw.  The bug is clearly described in the comment.
There is no optimization involved, in fact a bad optimization is removed.

As for your first fix, I assume you mean this:

+       // Sometimes gtk_events_pending is true, but gdk_event_handler
+       // receives nothing and does not increase the count.
+       // If we ignore these pending events, then we lock up,
+       // for example with continuos movements of vertical scroll bar.
+       if (!count) count = 1;


This basically introduces a busy wait, which is no good at all.  Note that Emacs is still running with SIGIO off with this patch, so while it may fix the symptoms, it does not fix the problem.

	Jan D.

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

From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 15801 <at> debbugs.gnu.org
Subject: Re: bug#15801: 24.3.50; bar scrolling freezes gtk emacs
Date: Sun, 01 Dec 2013 12:38:27 +0100

W dniu 2013-12-01 12:07, Jan Djärv pisze:
> has absolutely nothing to do with -nw.  The bug is clearly described in the comment.
> There is no optimization involved, in fact a bad optimization is removed.

I also read the commit message. Please type:

bzr log -r112892 -l 1

This is the commit I talk about since message 11 [1] in this bug report.

You said (in private message a moment ago) that you fixed a common bug 
in this commit. Please give the bug id or describe the bug.

Jarek

[1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15801#11

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Cc: 15801 <at> debbugs.gnu.org
Subject: Re: bug#15801: 24.3.50; bar scrolling freezes gtk emacs
Date: Sun, 1 Dec 2013 12:48:33 +0100

Hello.

1 dec 2013 kl. 12:38 skrev Jarek Czekalski <jarekczek <at> poczta.onet.pl>:

> 
> W dniu 2013-12-01 12:07, Jan Djärv pisze:
>> has absolutely nothing to do with -nw.  The bug is clearly described in the comment.
>> There is no optimization involved, in fact a bad optimization is removed.
> 
> I also read the commit message. Please type:
> 
> bzr log -r112892 -l 1
> 
> This is the commit I talk about since message 11 [1] in this bug report.
> 
> You said (in private message a moment ago) that you fixed a common bug in this commit. Please give the bug id or describe the bug.

Not all bug fixes have a bug report.
I say again: the bug fixed is described in the comment:

  /* Do not try to optimize with an initial check with g_main_context_pending
     and a call to pselect if it returns false.  If Gdk has a timeout for 0.01
     second, and Emacs has a timeout for 1 second, g_main_context_pending will
     return false, but the timeout will be 1 second, thus missing the gdk
     timeout with a lot.  */

	Jan D.


> 
> Jarek
> 
> [1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15801#11

Message #59 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: Re: bug#15801: 24.3.50; bar scrolling freezes gtk emacs
Date: Mon, 02 Dec 2013 09:04:59 +0100

Jan, you got lost with the commit 112892 of yours. You say it has 
nothing to do with -nw, but in the message log you mention -nw. Please 
have one more look at it (at the whole commit), to see that I'm right. 
That's important, because I see a real problem with this commit.

When you created xgselect.c file in r98730 you placed the following 
lines there:

              |   /* Update event sources in GLib. */
              |   g_main_context_pending (context);

As I understand it is that this call is important to update glib sources 
(possibly glib file descriptors too - my guess).

In r109774 Paul removes this comment, while keeping the call to 
g_main_context_pending, but conditionally:

+  if (! (x_in_use
+     && g_main_context_pending (context = g_main_context_default ())))

In r112892 you say that call to g_main_context_pending is not needed at 
all, because it was a bad optimization, which you corrected.

This is a mistake, isn't it?

As a side note: I'm still trying to investigate my freeze. So far I know 
that in the "freezed" state xgselect returns non-zero, while 
XTread_socket returns 0. And this happens repeatedly and very quickly.

Side note 2: detailed description of the bug being fixed in a commit is 
very important. Otherwise after just a few months we don't know what we 
really fixed. A link to a bug report or to a discussion on a mailing 
list would be very valueable. We don't have this information in commit 
r112892.

Another concern when I analyze xgselect is why we increase the number of 
tested selectors over the number requested by the caller? If a caller 
receives a positive number, it thinks that there is something to read. 
But it will check only the descriptors up to the number it specified in 
the call. This doesn't make sense to me. Shouldn't it be specified in 
the documentation of xgselect, that it may surprise caller with false 
positives? This is not the usual behaviour of select-like calls, is it? 
And this is something that was changed by your commit. Previously a 
standard pselect was returned (under some circumstances). After that, 
the extended version, with false positives.

Jarek

Message #62 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: Mon, 02 Dec 2013 09:18:11 +0100

The last paragraph, about false positives, seems like it was my mistake. 
I'm sorry for that.

Jarek

Message #65 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: Mon, 02 Dec 2013 18:11:20 +0100

Anyway adding a g_main_context_pending call alone does not solve the 
issue. Explaining the mystery of removal of this call may not be worth 
its time. I'll concentrate on SIGIO as suggested by Jan and report when 
I have something on this subject.

Message #68 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: Tue, 03 Dec 2013 23:27:45 +0100

It's not about sigio. Inside xg_select, which is called with high 
frequency inside the freeze, the sigmask has not sigio set. Even if I 
try to force the freeze calling unrequest_sigio (and sigmask indeed 
changes), still the behaviour does not differ. Emacs is responsive until 
I want to play scrolling bars with it.

What I discovered so far:

1. Inside the freeze xg_select always returns 1, due to active 
descriptor 7 (in my case it's number 7). This is the descriptor received 
from ConnectionNumber (x11) and inserted into input_wait_mask through 
add_keyboard_wait_descriptor
2. gtk detects no events pending during the freeze
3. gdk event filter is not called

This contradiction (input from x11, but no gtk events) suggests to me 
that something's wrong between gtk and x, in gdk x11 module. So gtk 
version may be important. It is included in the initial report, 3.8.4. 
No change in 3.8.6-1. When I compiled 3.11.2 (the hottest gtk tag), 
emacs does not freeze, but displays white screen instead of the text 
area, only momentarily showing traces of the true content.

I'll report again when I know something for sure. I'm not giving up yet :)

By the way: g_main_context_query call in xg_select is theoretically 
illegal, because it should be wrapped inside g_main_context_acquire. 
Also g_main_context_prepare is suggested before "query". Anyway adding 
both these calls does not help the freeze.

Jarek

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)]

Message #74 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: 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

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Cc: 15801 <at> debbugs.gnu.org
Subject: Re: bug#15801: 24.3.50; bar scrolling freezes gtk emacs
Date: Sat, 7 Dec 2013 15:34:10 +0100

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

Hello.

5 dec 2013 kl. 18:08 skrev Jarek Czekalski <jarekczek <at> poczta.onet.pl>:

> 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.

[cpuinfo (application/octet-stream, attachment)]

Message #80 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: Sun, 08 Dec 2013 17:14:15 +0100

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

This time the posts consists of 3 parts: the poll, the bug, the patch.

THE POLL about reproducability

Jan - almost unable to reproduce using gtk 3.8.6 and 2 core Intel 
2.6GHz. On a faster machine never reproduced.
Steve Berman - can't touch the scroll bar without a freeze, gtk 3.10.2, 
AMD 3.4 GHz
Jarek - reproducing with a couple of scroll bar movements, gtk 3.8.x, 
Celeron 3GHz

So at least 2 people are reproducing easily, including me.

THE BUG in gtk

I submitted a bug in gtk [1], as I suspect the motion events compression 
introduced in 3.7.10 is responsible for the freeze. Unfortunately I 
cannot reproduce without Emacs. Simply inserting gtk main loop call 
inside motion event handler in gtk3demo app, plus some random delays, 
does not allow to freeze it. Maybe breaking the chain of motion events 
with something different is necessary.

In gtk 3.10 It will be possible to switch off the motion events 
compression, as it introduces also another problems, as reported in gtk 
bug [2], "motion_compression hurts precision for drawing". The switch is 
not planned to be merged into 3.8.

In my opinion gtk with clocks and motion compression does not make sure 
that the pausing/unpausing of events is always paired. Unpaired pause 
results in a freeze. However the requirements for the freeze may be very 
difficult to meet, thus the bug remains unproven.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=719883
[2] https://bugzilla.gnome.org/show_bug.cgi?id=702392

THE PATCH for Emacs

Emacs is not free of bugs in this area. I consider a bug the behaviour, 
when inside a gtk signal handler (scroll bar event) we enter another gtk 
event loop.

That's because of (almost) undocumented feature of unblock_input. It 
does not only process the events that came during block/unblock pair, 
but it also processes the queue of events that were not processed 
before. Emacs seems to rely on calls to ublock_input, which trigger 
reading the input. A function without block/unblock statements would 
actually be never interrupted. When block/unblock pair is inserted, it 
will cause input handling at the moment of unblock_input call. That does 
not hurt much, as stated by Stephan in [3], but introduces a 
counter-intuitive feature: the function containing block/unblock is 
usually safer than the one not containing them. It is most important in 
callbacks. A callback containing block/unblock is unsafe, unless it is 
contained in an outer block/unblock pair.

The patch introduces block/unblock input wrapper around the glib main 
loop in xgselect.c, thus preventing main loop recursion. The recursion 
was occuring when unblock_input was called inside the scroll bar 
callback. Full backtrace attached.

This time I believe the patch is something that should be applied. It 
contains also comments, that should make some features better noticable. 
One of the comments is for unblock_input. I hope it's agreeable.

Jarek

[3] 
http://emacs.1067599.n5.nabble.com/GTK-stack-busting-loop-tp219788p219791.html

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

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

Message #83 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: Mon, 09 Dec 2013 00:29:51 +0100

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

Fixing compilation warning in the patch, missing include blockinput.h.

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

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Cc: 15801 <at> debbugs.gnu.org
Subject: Re: bug#15801: 24.3.50; bar scrolling freezes gtk emacs
Date: Wed, 11 Dec 2013 20:52:28 +0100

Hello.

9 dec 2013 kl. 00:29 skrev Jarek Czekalski <jarekczek <at> poczta.onet.pl>:

> Fixing compilation warning in the patch, missing include blockinput.h.
> 
> <scroll_freeze_2_1.txt>

I'll have to review this, but have no time right now.  Maybe next week.

	Jan D.

Message #89 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: Re: bug#15801: 24.3.50; bar scrolling freezes gtk emacs
Date: Fri, 20 Dec 2013 07:32:15 +0100

My Emacs assignment is filed in FSF under number 866994.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Cc: 15801 <at> debbugs.gnu.org
Subject: Re: bug#15801: 24.3.50; bar scrolling freezes gtk emacs
Date: Fri, 20 Dec 2013 10:58:56 +0200

> Date: Fri, 20 Dec 2013 07:32:15 +0100
> From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
> 
> My Emacs assignment is filed in FSF under number 866994.

Sorry, I don't see it in the FSF records yet.  Are you sure the mail
exchange between you and the FSF is completed?  If so, please ask the
FSF clerk who sent you the mail response to update the records.

Message #97 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: 24.3.50; bar scrolling freezes gtk emacs
Date: Mon, 21 Apr 2014 12:34:18 +0200

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

Patch rebased for r117003.

[scroll_freeze_2_1_r117003.patch (text/x-diff, attachment)]

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Cc: 15801-done <at> debbugs.gnu.org
Subject: Re: bug#15801: 24.3.50; bar scrolling freezes gtk emacs
Date: Mon, 21 Apr 2014 11:56:20 -0400

> Patch rebased for r117003.

Thanks, installed in emacs-24, with some style fixes (please check the
differences in ChangeLog and in spacing).


        Stefan

Previous Next

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