bug#15801: 24.3.50; bar scrolling freezes gtk emacs

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jarek Czekalski]

[-- Attachment #1: Type: text/plain, Size: 9704 bytes --]


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


[-- Attachment #2: fix_scroll_hang_1_0.txt --]
[-- Type: text/plain, Size: 1649 bytes --]

=== modified file 'lisp/htmlfontify.el'
*** lisp/htmlfontify.el	2013-10-30 19:35:14 +0000
--- lisp/htmlfontify.el	2013-11-04 06:58:29 +0000
*************** You may also want to set `hfy-page-heade
*** 2410,2418 ****
      (load file 'NOERROR nil nil) ))
  
  \f
! ;;;### (autoloads nil "hfy-cmap" "hfy-cmap.el" "df4e418d0d8749ead9d32bb2c7a5bd56")
  ;;; Generated autoloads from hfy-cmap.el
  (push (purecopy '(htmlfontify 0 20)) package--builtin-versions)
  (autoload 'htmlfontify-load-rgb-file "hfy-cmap" "\
  Load an X11 style rgb.txt FILE.
  Search `hfy-rgb-load-path' if FILE is not specified.
--- 2410,2419 ----
      (load file 'NOERROR nil nil) ))
  
  \f
! ;;;### (autoloads nil "hfy-cmap" "hfy-cmap.el" "9fc09983e774dd0938661615b457fb59")
  ;;; Generated autoloads from hfy-cmap.el
  (push (purecopy '(htmlfontify 0 20)) package--builtin-versions)
+ 
  (autoload 'htmlfontify-load-rgb-file "hfy-cmap" "\
  Load an X11 style rgb.txt FILE.
  Search `hfy-rgb-load-path' if FILE is not specified.

=== modified file 'src/xterm.c'
*** src/xterm.c	2013-10-29 16:08:08 +0000
--- src/xterm.c	2013-11-04 18:20:27 +0000
*************** XTread_socket (struct terminal *terminal
*** 7060,7065 ****
--- 7060,7071 ----
        current_count = -1;
        current_hold_quit = 0;
  
+       // 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;
+ 
        if (current_finish == X_EVENT_GOTO_OUT)
          break;
      }

bug#15801: 15801: commit identified

[Jarek Czekalski]

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

bug#15801: it's a different revision, 112892

[Jarek Czekalski]

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

bug#15801: it's a different revision, 112892

[Jan Djärv]

Hello.

6 nov 2013 kl. 20:48 skrev Jarek Czekalski <jarekczek@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@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
> 
> 

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jarek Czekalski]

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

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jan Djärv]

Hello.

21 nov 2013 kl. 08:25 skrev Jarek Czekalski <jarekczek@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.

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Sat, 30 Nov 2013 12:41:27 +0100
> Cc: 15801@debbugs.gnu.org,
>  Eli Zaretskii <eliz@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.

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jan Djärv]

Hello.

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

>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Date: Sat, 30 Nov 2013 12:41:27 +0100
>> Cc: 15801@debbugs.gnu.org,
>> Eli Zaretskii <eliz@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.

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Sat, 30 Nov 2013 13:51:11 +0100
> Cc: Jarek Czekalski <jarekczek@poczta.onet.pl>,
>  15801@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 ;-)

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jan Djärv]

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

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

Drat!  Fixed.

	Jan D.

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jarek Czekalski]

[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]

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


[-- Attachment #2: req_sigio_1_0.txt --]
[-- Type: text/plain, Size: 3177 bytes --]

=== modified file 'src/xdisp.c'
--- src/xdisp.c	2013-11-30 14:03:53 +0000
+++ src/xdisp.c	2013-11-30 16:04:59 +0000
@@ -13119,13 +13119,28 @@
     }
 }
 
-#define STOP_POLLING					\
-do { if (! polling_stopped_here) stop_polling ();	\
-       polling_stopped_here = 1; } while (0)
+#define STOP_POLLING                                      \
+do {                                                      \
+  if (! polling_stopped_here) stop_polling ();            \
+  polling_stopped_here = 1;                               \
+  /* Prevent various kinds of signals during display      \
+     update.  stdio is not robust about handling          \
+     signals, which can cause an apparent I/O error.  */  \
+  if (interrupt_input)                                    \
+    unrequest_sigio ();                                   \
+} while (0)
 
-#define RESUME_POLLING					\
-do { if (polling_stopped_here) start_polling ();	\
-       polling_stopped_here = 0; } while (0)
+#define RESUME_POLLING                                                 \
+do {                                                                   \
+  if (polling_stopped_here) start_polling ();	                       \
+  polling_stopped_here = 0;                                            \
+  /* Start SIGIO interrupts coming again.  Having them off during the  \
+     code above makes it less likely one will discard output, but not  \
+     impossible, since there might be stuff in the system buffer here. \
+     But it is much hairier to try to do anything about that.  */      \
+  if (interrupt_input)                                                 \
+    request_sigio ();                                                  \
+} while (0)
 
 
 /* Perhaps in the future avoid recentering windows if it
@@ -13627,11 +13642,6 @@
 			goto retry_frame;
 		    }
 
-		  /* Prevent various kinds of signals during display
-		     update.  stdio is not robust about handling
-		     signals, which can cause an apparent I/O error.  */
-		  if (interrupt_input)
-		    unrequest_sigio ();
 		  STOP_POLLING;
 
 		  pending |= update_frame (f, 0, 0);
@@ -13684,11 +13694,6 @@
       if (sf->fonts_changed)
 	goto retry;
 
-      /* Prevent various kinds of signals during display update.
-	 stdio is not robust about handling signals,
-	 which can cause an apparent I/O error.  */
-      if (interrupt_input)
-	unrequest_sigio ();
       STOP_POLLING;
 
       if (FRAME_VISIBLE_P (sf) && !FRAME_OBSCURED_P (sf))
@@ -13761,12 +13766,6 @@
       windows_or_buffers_changed = 0;
     }
 
-  /* Start SIGIO interrupts coming again.  Having them off during the
-     code above makes it less likely one will discard output, but not
-     impossible, since there might be stuff in the system buffer here.
-     But it is much hairier to try to do anything about that.  */
-  if (interrupt_input)
-    request_sigio ();
   RESUME_POLLING;
 
   /* If a frame has become visible which was not before, redisplay
@@ -13819,8 +13818,6 @@
 #endif /* HAVE_WINDOW_SYSTEM */
 
  end_of_redisplay:
-  if (interrupt_input && interrupts_deferred)
-    request_sigio ();
 
   unbind_to (count, Qnil);
   RESUME_POLLING;

bug#15801: 24.3.50; bar scrolling freezes gtk emacs - stdout warning

[Jarek Czekalski]

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

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jarek Czekalski]

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

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Eli Zaretskii]

> Date: Sat, 30 Nov 2013 19:11:40 +0100
> From: Jarek Czekalski <jarekczek@poczta.onet.pl>
> CC: Jan Djärv <jan.h.d@swipnet.se>, 
>  15801@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.

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jan Djärv]

Hello.

30 nov 2013 kl. 18:04 skrev Jarek Czekalski <jarekczek@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.

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jan Djärv]

1 dec 2013 kl. 11:43 skrev Jarek Czekalski <jarekczek@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.

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jarek Czekalski]

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

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jan Djärv]

Hello.

1 dec 2013 kl. 12:38 skrev Jarek Czekalski <jarekczek@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

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jarek Czekalski]

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

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jarek Czekalski]

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

Jarek

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jarek Czekalski]

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.

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jarek Czekalski]

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

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jarek Czekalski]

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

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


[-- Attachment #2: backtrace.txt --]
[-- Type: text/plain, Size: 12092 bytes --]

Script started on Wed 04 Dec 2013 09:22:42 PM CET
jcdeb:/home# gdb --args emacs -Q
GNU gdb (GDB) 7.6.1 (Debian 7.6.1-1)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/bin/emacs-24.3.50...done.
(gdb) start
Temporary breakpoint 1 at 0x8058350: file emacs.c, line 688.
Starting program: /usr/local/bin/emacs -Q
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".

Temporary breakpoint 1, main (argc=2, argv=0xbffff544) at emacs.c:688
688	{
(gdb) break _gdk_display_pause_events
Breakpoint 2 at 0xb78f2f40: file gdkdisplay.c, line 2012.
(gdb) break _gdk_display_pause_events\b\b\b\b\b\b\b\b\b\b\b\b^[[1@u^[[1@n
Breakpoint 3 at 0xb78f2f50: file gdkdisplay.c, line 2018.
(gdb) cont
Continuing.
[New Thread 0xb5f07b40 (LWP 29235)]
[New Thread 0xb552fb40 (LWP 29237)]
[New Thread 0xb4bffb40 (LWP 29239)]

Breakpoint 2, _gdk_display_pause_events (display=display@entry=0x8858840)
    at gdkdisplay.c:2012
2012	{
(gdb) backtrace
#0  _gdk_display_pause_events (display=display@entry=0x8858840)
    at gdkdisplay.c:2012
#1  0xb78ffa2e in gdk_window_flush_events (clock=0x8861150, data=0x885f980)
    at gdkwindow.c:11611
#2  0xb7551339 in g_cclosure_marshal_VOID__VOIDv (closure=0x85c9570, 
    return_value=0x0, instance=0x8861150, args=0xbfffe978 "", 
    marshal_data=0x0, n_params=0, param_types=0x0)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gmarshal.c:115
#3  0xb754f8de in _g_closure_invoke_va (closure=closure@entry=0x85c9570, 
    return_value=return_value@entry=0x0, instance=instance@entry=0x8861150, 
    args=args@entry=0xbfffe978 "", n_params=0, param_types=0x0)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gclosure.c:840
#4  0xb7568237 in g_signal_emit_valist (instance=instance@entry=0x8861150, 
    signal_id=signal_id@entry=136, detail=detail@entry=0, 
    var_args=var_args@entry=0xbfffe978 "")
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gsignal.c:3234
#5  0xb7569291 in g_signal_emit_by_name (instance=instance@entry=0x8861150, 
    detailed_signal=detailed_signal@entry=0xb7938973 "flush-events")
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gsignal.c:3424
#6  0xb78f936d in gdk_frame_clock_flush_idle (data=0x8861150)
    at gdkframeclockidle.c:312
#7  0xb78eafc5 in gdk_threads_dispatch (data=data@entry=0x8a0dfb0) at gdk.c:788
#8  0xb74850b1 in g_timeout_dispatch (source=source@entry=0x89ee6a8, 
---Type <return> to continue, or q <return> to quit---
    callback=0xb78eaf90 <gdk_threads_dispatch>, user_data=0x8a0dfb0)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:4413
#9  0xb748442e in g_main_dispatch (context=0x884a1e8, context@entry=0x883a220)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3054
#10 g_main_context_dispatch (context=context@entry=0x884a1e8)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3630
#11 0xb74847d8 in g_main_context_iterate (context=context@entry=0x884a1e8, 
    block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3701
#12 0xb7484898 in g_main_context_iteration (context=0x884a1e8, 
    context@entry=0x0, may_block=may_block@entry=1)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3762
#13 0xb7af0bd8 in gtk_main_iteration () at gtkmain.c:1260
#14 0x080f0091 in XTread_socket (terminal=0x8737818, hold_quit=0xbfffeb0c)
    at xterm.c:7077
#15 0x08123519 in gobble_input () at keyboard.c:6841
#16 0x08122f95 in handle_async_input () at keyboard.c:7081
#17 process_pending_signals () at keyboard.c:7095
#18 0x08171939 in Fmake_list (length=length@entry=4, init=138857410)
    at alloc.c:2597
#19 0x08190188 in concat (nargs=nargs@entry=1, args=args@entry=0xbfffec30, 
    target_type=Lisp_Cons, last_special=last_special@entry=false) at fns.c:578
#20 0x0819070e in Fcopy_sequence (arg=141242022) at fns.c:446
---Type <return> to continue, or q <return> to quit---
#21 0x08121e06 in timer_check () at keyboard.c:4559
#22 0x0812233b in readable_events (flags=flags@entry=1) at keyboard.c:3439
#23 0x0812361f in get_input_pending (flags=flags@entry=1) at keyboard.c:6756
#24 0x08126692 in detect_input_pending_run_timers (
    do_display=do_display@entry=true) at keyboard.c:9879
#25 0x081c678f in wait_reading_process_output (time_limit=<optimized out>, 
    nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, 
    do_display=do_display@entry=true, wait_for_cell=138857410, 
    wait_proc=wait_proc@entry=0x0, just_wait_proc=just_wait_proc@entry=0)
    at process.c:4680
#26 0x08062431 in sit_for (timeout=120, reading=reading@entry=true, 
    display_option=display_option@entry=1) at dispnew.c:5800
#27 0x08127383 in read_char (commandflag=1, map=map@entry=141054470, 
    prev_event=138857410, used_mouse_menu=used_mouse_menu@entry=0xbffff25b, 
    end_time=end_time@entry=0x0) at keyboard.c:2805
#28 0x0812865e in read_key_sequence (keybuf=keybuf@entry=0xbffff2f8, 
    prompt=138857410, dont_downcase_last=dont_downcase_last@entry=false, 
    can_return_switch_frame=can_return_switch_frame@entry=true, 
    fix_current_buffer=fix_current_buffer@entry=true, 
    prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
    at keyboard.c:9074
#29 0x0812a016 in command_loop_1 () at keyboard.c:1445
#30 0x08189163 in internal_condition_case (
---Type <return> to continue, or q <return> to quit---
    bfun=bfun@entry=0x8129e60 <command_loop_1>, handlers=138890506, 
    hfun=hfun@entry=0x8121750 <cmd_error>) at eval.c:1344
#31 0x0811d235 in command_loop_2 (ignore=138857410) at keyboard.c:1170
#32 0x08189093 in internal_catch (tag=138888554, 
    func=func@entry=0x811d210 <command_loop_2>, arg=138857410) at eval.c:1108
#33 0x081213a2 in command_loop () at keyboard.c:1149
#34 recursive_edit_1 () at keyboard.c:777
#35 0x08121663 in Frecursive_edit () at keyboard.c:841
#36 0x08058e88 in main (argc=<optimized out>, argv=0xbffff544) at emacs.c:1598
(gdb) cont
Continuing.

Breakpoint 3, _gdk_display_unpause_events (display=0x8858840)
    at gdkdisplay.c:2018
2018	{
(gdb) backtrace
#0  _gdk_display_unpause_events (display=0x8858840) at gdkdisplay.c:2018
#1  0xb78ff9f3 in gdk_window_resume_events (clock=0x8861150, data=0x885f980)
    at gdkwindow.c:11639
#2  0xb7551339 in g_cclosure_marshal_VOID__VOIDv (closure=0x85c9610, 
    return_value=0x0, instance=0x8861150, args=0xbfffe948 "?\022", 
    marshal_data=0x0, n_params=0, param_types=0x0)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gmarshal.c:115
#3  0xb754f8de in _g_closure_invoke_va (closure=closure@entry=0x85c9610, 
    return_value=return_value@entry=0x0, instance=instance@entry=0x8861150, 
    args=args@entry=0xbfffe948 "?\022", n_params=0, param_types=0x0)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gclosure.c:840
#4  0xb7568237 in g_signal_emit_valist (instance=instance@entry=0x8861150, 
    signal_id=signal_id@entry=142, detail=detail@entry=0, 
    var_args=var_args@entry=0xbfffe948 "?\022")
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gsignal.c:3234
#5  0xb7569291 in g_signal_emit_by_name (instance=instance@entry=0x8861150, 
    detailed_signal=detailed_signal@entry=0xb79389a0 "resume-events")
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gsignal.c:3424
#6  0xb78f98d4 in gdk_frame_clock_paint_idle (data=0x8861150)
    at gdkframeclockidle.c:457
#7  0xb78eafc5 in gdk_threads_dispatch (data=data@entry=0x8a0df80) at gdk.c:788
#8  0xb74850b1 in g_timeout_dispatch (source=source@entry=0x88e9c80, 
    callback=0xb78eaf90 <gdk_threads_dispatch>, user_data=0x8a0df80)
---Type <return> to continue, or q <return> to quit---
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:4413
#9  0xb748442e in g_main_dispatch (context=0x884a1e8, context@entry=0x883a220)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3054
#10 g_main_context_dispatch (context=context@entry=0x884a1e8)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3630
#11 0xb74847d8 in g_main_context_iterate (context=context@entry=0x884a1e8, 
    block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3701
#12 0xb7484898 in g_main_context_iteration (context=0x884a1e8, 
    context@entry=0x0, may_block=may_block@entry=1)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3762
#13 0xb7af0bd8 in gtk_main_iteration () at gtkmain.c:1260
#14 0x080f0091 in XTread_socket (terminal=0x8737818, hold_quit=0xbfffeb0c)
    at xterm.c:7077
#15 0x08123519 in gobble_input () at keyboard.c:6841
#16 0x08122f95 in handle_async_input () at keyboard.c:7081
#17 process_pending_signals () at keyboard.c:7095
#18 0x08171939 in Fmake_list (length=length@entry=4, init=138857410)
    at alloc.c:2597
#19 0x08190188 in concat (nargs=nargs@entry=1, args=args@entry=0xbfffec30, 
    target_type=Lisp_Cons, last_special=last_special@entry=false) at fns.c:578
#20 0x0819070e in Fcopy_sequence (arg=141242022) at fns.c:446
#21 0x08121e06 in timer_check () at keyboard.c:4559
---Type <return> to continue, or q <return> to quit---
#22 0x0812233b in readable_events (flags=flags@entry=1) at keyboard.c:3439
#23 0x0812361f in get_input_pending (flags=flags@entry=1) at keyboard.c:6756
#24 0x08126692 in detect_input_pending_run_timers (
    do_display=do_display@entry=true) at keyboard.c:9879
#25 0x081c678f in wait_reading_process_output (time_limit=<optimized out>, 
    nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, 
    do_display=do_display@entry=true, wait_for_cell=138857410, 
    wait_proc=wait_proc@entry=0x0, just_wait_proc=just_wait_proc@entry=0)
    at process.c:4680
#26 0x08062431 in sit_for (timeout=120, reading=reading@entry=true, 
    display_option=display_option@entry=1) at dispnew.c:5800
#27 0x08127383 in read_char (commandflag=1, map=map@entry=141054470, 
    prev_event=138857410, used_mouse_menu=used_mouse_menu@entry=0xbffff25b, 
    end_time=end_time@entry=0x0) at keyboard.c:2805
#28 0x0812865e in read_key_sequence (keybuf=keybuf@entry=0xbffff2f8, 
    prompt=138857410, dont_downcase_last=dont_downcase_last@entry=false, 
    can_return_switch_frame=can_return_switch_frame@entry=true, 
    fix_current_buffer=fix_current_buffer@entry=true, 
    prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
    at keyboard.c:9074
#29 0x0812a016 in command_loop_1 () at keyboard.c:1445
#30 0x08189163 in internal_condition_case (
    bfun=bfun@entry=0x8129e60 <command_loop_1>, handlers=138890506, 
---Type <return> to continue, or q <return> to quit---
    hfun=hfun@entry=0x8121750 <cmd_error>) at eval.c:1344
#31 0x0811d235 in command_loop_2 (ignore=138857410) at keyboard.c:1170
#32 0x08189093 in internal_catch (tag=138888554, 
    func=func@entry=0x811d210 <command_loop_2>, arg=138857410) at eval.c:1108
#33 0x081213a2 in command_loop () at keyboard.c:1149
#34 recursive_edit_1 () at keyboard.c:777
#35 0x08121663 in Frecursive_edit () at keyboard.c:841
#36 0x08058e88 in main (argc=<optimized out>, argv=0xbffff544) at emacs.c:1598
(gdb) delete
Delete all breakpoints? (y or n) y
(gdb) cont
Continuing.
[Thread 0xb4bffb40 (LWP 29239) exited]
[Thread 0xb552fb40 (LWP 29237) exited]
[Thread 0xb5f07b40 (LWP 29235) exited]
[Inferior 1 (process 29197) exited normally]
(gdb) quit
jcdeb:/home# exit
exit

Script done on Wed 04 Dec 2013 09:23:44 PM CET

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[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"

Jarek

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jan Djärv]

[-- Attachment #1: Type: text/plain, Size: 1981 bytes --]

Hello.

5 dec 2013 kl. 18:08 skrev Jarek Czekalski <jarekczek@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.

[-- Attachment #2: cpuinfo --]
[-- Type: application/octet-stream, Size: 585 bytes --]

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Intel(R) Core(TM)2 Duo CPU     T9550  @ 2.66GHz
stepping	: 10
cpu MHz		: 2653.000
cache size	: 6144 KB
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc nopl xtopology pni ssse3 cx16 sse4_1 x2apic xsave hypervisor lahf_lm ida arat
bogomips	: 5306.00
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jarek Czekalski]

[-- Attachment #1: Type: text/plain, Size: 3025 bytes --]

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


[-- Attachment #2: reent_bt.txt --]
[-- Type: text/plain, Size: 13736 bytes --]

Script started on Sat 07 Dec 2013 10:43:18 AM CET
jcdeb:/m/usr/src/gtk+# gdb\b \b\b \b\b \bbs=1 gdb --args emacs -Q
GNU gdb (GDB) 7.6.1 (Debian 7.6.1-1)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/bin/emacs-24.3.50...done.
(gdb) start
Temporary breakpoint 1 at 0x80582f0: file ../../emacs-checkout/src/emacs.c, line 688.
Starting program: /usr/local/bin/emacs -Q
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".

Temporary breakpoint 1, main (argc=2, argv=0xbffff554)
    at ../../emacs-checkout/src/emacs.c:688
688	{
(gdb) break gdkframeclockidle.c:329 if bsnested>1
Breakpoint 2 at 0xb78f59bf: file gdkframeclockidle.c, line 329.
(gdb) cont
Continuing.
[New Thread 0xb5f2db40 (LWP 17607)]
<[New Thread 0xb5554b40 (LWP 17609)]
[New Thread 0xb4bffb40 (LWP 17611)]
<m<>>mPmmmpmmmPmpmmmPpmmmP<p<m>mPmmmpmmPmp<m>mPmpmmmmPpmmPmmpmmmmPpm<m'mF'@mf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mF'@m'@mf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}mmPpm'mF'@mf(0mP{m)p}m'mF'@mf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}mmP'mF'@mf(0{m)p}mmP'mFpmf(0mP{m)p}m'mF'@mf(0mP{m)p}m'mF'@m'@mf(0mP{m)p}m'mF'@m'@mf(0mP{m)p}m'mFmP'@mf(0pmPpm'mF{mP)mfp}mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mFf(0mP{m)p}m'mF'@m'@mf(0mP{m)p}m'mFmP'@mf(0{m)p}m'mF'@m'@mf(0mP{m)p}m'mFf(0{mP)p}m'mFf(0{mP)p}m'mF'@mf(0mP{m)p}m'mF'@mf(0mP{m)p}m'mF'@mf(0mP{m)p}mmP'mFf(0pmPpm{mP)mp}m'mF'@m'@m'@mf(0'mFmPfpmFPf(1$
Breakpoint 2, gdk_frame_clock_flush_idle (data=0x85e4950)
    at gdkframeclockidle.c:329
329	  g_signal_emit_by_name (G_OBJECT (clock), "flush-events");
(gdb) bt
#0  gdk_frame_clock_flush_idle (data=0x85e4950) at gdkframeclockidle.c:329
#1  0xb78e7075 in gdk_threads_dispatch (data=data@entry=0x8a13230) at gdk.c:788
#2  0xb74810b1 in g_timeout_dispatch (source=source@entry=0x8a70ef0, 
    callback=0xb78e7040 <gdk_threads_dispatch>, user_data=0x8a13230)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:4413
#3  0xb748042e in g_main_dispatch (context=0x85cd918, context@entry=0x85bd9a0)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3054
#4  g_main_context_dispatch (context=context@entry=0x85cd918)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3630
#5  0xb74807d8 in g_main_context_iterate (context=context@entry=0x85cd918, 
    block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3701
#6  0xb7480898 in g_main_context_iteration (context=0x85cd918, 
    context@entry=0x0, may_block=may_block@entry=1)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3762
#7  0xb7aedbd8 in gtk_main_iteration () at gtkmain.c:1260
#8  0x080f13a1 in XTread_socket (terminal=0x8773c10, hold_quit=0xbfffdc9c)
    at ../../emacs-checkout/src/xterm.c:7077
#9  0x08125329 in gobble_input () at ../../emacs-checkout/src/keyboard.c:6841
#10 0x08124d05 in handle_async_input ()
    at ../../emacs-checkout/src/keyboard.c:7081
#11 process_pending_signals () at ../../emacs-checkout/src/keyboard.c:7095
#12 0x081264e3 in unblock_input () at ../../emacs-checkout/src/keyboard.c:7124
---Type <return> to continue, or q <return> to quit---
#13 0x080eeca8 in x_send_scroll_bar_event (window=<optimized out>, 
    part=<optimized out>, portion=<optimized out>, whole=whole@entry=1617275)
    at ../../emacs-checkout/src/xterm.c:4299
#14 0x080f0832 in xg_scroll_callback (range=range@entry=0x84c8220, 
    scroll=GTK_SCROLL_JUMP, value=value@entry=1980707.359550562, 
    user_data=user_data@entry=0x8a06838)
    at ../../emacs-checkout/src/xterm.c:4472
#15 0xb7aef2f3 in _gtk_marshal_BOOLEAN__ENUM_DOUBLE (closure=0x8a1f458, 
    return_value=0xbfffdee0, n_param_values=3, param_values=0xbfffdf50, 
    invocation_hint=0xbfffdefc, marshal_data=0x0) at gtkmarshalers.c:442
#16 0xb754b69e in g_closure_invoke (closure=0x8a1f458, 
    return_value=return_value@entry=0xbfffdee0, n_param_values=3, 
    param_values=param_values@entry=0xbfffdf50, 
    invocation_hint=invocation_hint@entry=0xbfffdefc)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gclosure.c:777
#17 0xb755d149 in signal_emit_unlocked_R (node=node@entry=0x84c5cc8, detail=0, 
    instance=0x84c8220, emission_return=emission_return@entry=0xbfffe010, 
    instance_and_params=0xbfffdf50)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gsignal.c:3584
#18 0xb7564884 in g_signal_emit_valist (instance=instance@entry=0x84c8220, 
    signal_id=signal_id@entry=152, detail=detail@entry=0, 
    var_args=0xbfffe0c8 "üàÿ¿\230u÷", var_args@entry=0xbfffe0bc "\001")
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gsignal.c:3338
---Type <return> to continue, or q <return> to quit---
#19 0xb7564dd3 in g_signal_emit (instance=instance@entry=0x84c8220, 
    signal_id=152, detail=detail@entry=0)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gsignal.c:3384
#20 0xb7b3f62a in update_slider_position (range=range@entry=0x84c8220, 
    mouse_x=<optimized out>, mouse_y=299) at gtkrange.c:2746
#21 0xb7b3fa4e in gtk_range_motion_notify (widget=0x84c8220, event=0x8519770)
    at gtkrange.c:2911
#22 0xb7aeec16 in _gtk_marshal_BOOLEAN__BOXEDv (closure=0x85bc6a8, 
    return_value=0xbfffe268, instance=0x84c8220, 
    args=0xbfffe33c "p\227Q\b\\ãÿ¿\020\227[\b\200dL\bh\017æ·çÒ·h\017æ· \202L\b", marshal_data=0xb7b3f990 <gtk_range_motion_notify>, n_params=1, 
    param_types=0x85bbdc8) at gtkmarshalers.c:130
#23 0xb754a077 in g_type_class_meta_marshalv (closure=0x85bc6a8, 
    return_value=0xbfffe268, instance=0x84c8220, 
    args=0xbfffe33c "p\227Q\b\\ãÿ¿\020\227[\b\200dL\bh\017æ·çÒ·h\017æ· \202L\b", marshal_data=0xcc, n_params=1, param_types=0x85bbdc8)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gclosure.c:997
#24 0xb754b8de in _g_closure_invoke_va (closure=closure@entry=0x85bc6a8, 
    return_value=return_value@entry=0xbfffe268, 
    instance=instance@entry=0x84c8220, 
    args=args@entry=0xbfffe33c "p\227Q\b\\ãÿ¿\020\227[\b\200dL\bh\017æ·çÒ·h\017æ· \202L\b", n_params=1, param_types=0x85bbdc8)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gclosure.c:840
---Type <return> to continue, or q <return> to quit---
#25 0xb7564237 in g_signal_emit_valist (instance=instance@entry=0x84c8220, 
    signal_id=signal_id@entry=32, detail=detail@entry=0, 
    var_args=var_args@entry=0xbfffe33c "p\227Q\b\\ãÿ¿\020\227[\b\200dL\bh\017æ·çÒ·h\017æ· \202L\b")
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gsignal.c:3234
#26 0xb7564dd3 in g_signal_emit (instance=instance@entry=0x84c8220, 
    signal_id=32, detail=detail@entry=0)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gsignal.c:3384
#27 0xb7c2d8fb in gtk_widget_event_internal (widget=widget@entry=0x84c8220, 
    event=event@entry=0x8519770) at gtkwidget.c:6722
#28 0xb7c2dbd5 in gtk_widget_event (widget=widget@entry=0x84c8220, 
    event=event@entry=0x8519770) at gtkwidget.c:6379
#29 0xb7aeca25 in propagate_event_up (topmost=<optimized out>, 
    event=<optimized out>, widget=0x84c8220) at gtkmain.c:2393
#30 propagate_event (widget=<optimized out>, event=0x8519770, captured=0, 
    topmost=0x0) at gtkmain.c:2501
#31 0xb7aee810 in gtk_main_do_event (event=0x8519770) at gtkmain.c:1716
#32 0xb78f052c in _gdk_event_emit (event=event@entry=0x8519770)
    at gdkevents.c:71
#33 0xb78ef0f8 in _gdk_display_flush_events (display=display@entry=0x85dc040)
    at gdkdisplay.c:2039
#34 0xb78fbec6 in gdk_window_flush_events (clock=0x85e4950, data=0x85e2980)
    at gdkwindow.c:11610
---Type <return> to continue, or q <return> to quit---
#35 0xb754d339 in g_cclosure_marshal_VOID__VOIDv (closure=0x853a2f8, 
    return_value=0x0, instance=0x85e4950, args=0xbfffe6b8 "\001", 
    marshal_data=0x0, n_params=0, param_types=0x0)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gmarshal.c:115
#36 0xb754b8de in _g_closure_invoke_va (closure=closure@entry=0x853a2f8, 
    return_value=return_value@entry=0x0, instance=instance@entry=0x85e4950, 
    args=args@entry=0xbfffe6b8 "\001", n_params=0, param_types=0x0)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gclosure.c:840
#37 0xb7564237 in g_signal_emit_valist (instance=instance@entry=0x85e4950, 
    signal_id=signal_id@entry=136, detail=detail@entry=0, 
    var_args=var_args@entry=0xbfffe6b8 "\001")
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gsignal.c:3234
#38 0xb7565291 in g_signal_emit_by_name (instance=instance@entry=0x85e4950, 
    detailed_signal=detailed_signal@entry=0xb7934e13 "flush-events")
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gsignal.c:3424
#39 0xb78f59d1 in gdk_frame_clock_flush_idle (data=0x85e4950)
    at gdkframeclockidle.c:329
#40 0xb78e7075 in gdk_threads_dispatch (data=data@entry=0x8a13390) at gdk.c:788
#41 0xb74810b1 in g_timeout_dispatch (source=source@entry=0x85550c0, 
    callback=0xb78e7040 <gdk_threads_dispatch>, user_data=0x8a13390)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:4413
#42 0xb748042e in g_main_dispatch (context=0x85cd918, context@entry=0xb753c000)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3054
---Type <return> to continue, or q <return> to quit---
#43 g_main_context_dispatch (context=context@entry=0x85cd918)
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./glib/gmain.c:3630
#44 0x081ff178 in xg_select (fds_lim=<optimized out>, rfds=0xbfffed70, 
    wfds=0xbfffedf0, efds=0x0, timeout=0xbfffe7c8, sigmask=0x0)
    at ../../emacs-checkout/src/xgselect.c:147
#45 0x081cb30b in wait_reading_process_output (time_limit=<optimized out>, 
    nsecs=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, 
    wait_for_cell=138861506, wait_proc=wait_proc@entry=0x0, 
    just_wait_proc=just_wait_proc@entry=0)
    at ../../emacs-checkout/src/process.c:4584
#46 0x08062595 in sit_for (timeout=timeout@entry=120, 
    reading=reading@entry=true, display_option=display_option@entry=1)
    at ../../emacs-checkout/src/dispnew.c:5800
#47 0x081292a6 in read_char (commandflag=1, map=map@entry=142392614, 
    prev_event=138861506, used_mouse_menu=used_mouse_menu@entry=0xbffff25b, 
    end_time=end_time@entry=0x0) at ../../emacs-checkout/src/keyboard.c:2805
#48 0x0812a8a8 in read_key_sequence (keybuf=keybuf@entry=0xbffff308, 
    prompt=138861506, dont_downcase_last=false, dont_downcase_last@entry=10, 
    can_return_switch_frame=can_return_switch_frame@entry=true, 
    fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=false, 
    prevent_redisplay@entry=10, bufsize=30)
    at ../../emacs-checkout/src/keyboard.c:9074
#49 0x0812b9d6 in command_loop_1 () at ../../emacs-checkout/src/keyboard.c:1445
---Type <return> to continue, or q <return> to quit---
#50 0x0818d3aa in internal_condition_case (
    bfun=bfun@entry=0x812b820 <command_loop_1>, handlers=138894602, 
    hfun=hfun@entry=0x8123260 <cmd_error>)
    at ../../emacs-checkout/src/eval.c:1344
#51 0x08121515 in command_loop_2 (ignore=ignore@entry=138861506)
    at ../../emacs-checkout/src/keyboard.c:1170
#52 0x0818d2cd in internal_catch (tag=138892650, 
    func=func@entry=0x81214f0 <command_loop_2>, arg=138861506)
    at ../../emacs-checkout/src/eval.c:1108
#53 0x08122e72 in command_loop () at ../../emacs-checkout/src/keyboard.c:1149
#54 recursive_edit_1 () at ../../emacs-checkout/src/keyboard.c:777
#55 0x0812314b in Frecursive_edit () at ../../emacs-checkout/src/keyboard.c:841
#56 0x08058e28 in main (argc=<optimized out>, argv=0xbffff554)
    at ../../emacs-checkout/src/emacs.c:1598
(gdb) quit
A debugging session is active.

	Inferior 1 [process 17567] will be killed.

Quit anyway? (y or n) y
jcdeb:/m/usr/src/gtk+# exit
exit

Script done on Sat 07 Dec 2013 10:44:12 AM CET

[-- Attachment #3: scroll_freeze_2_0.txt --]
[-- Type: text/plain, Size: 3623 bytes --]

=== modified file 'src/ChangeLog'
*** src/ChangeLog	2013-12-08 08:05:36 +0000
--- src/ChangeLog	2013-12-08 16:00:41 +0000
***************
*** 1,3 ****
--- 1,9 ----
+ 2013-12-08  Jarek Czekalski  <jarekczek@poczta.onet.pl>
+ 
+ 	Fix freezing with scroll bars of GTK3 Toolkit (Bug#15801).
+ 	* keyboard.c: A comment to unblock_input.
+ 	* xgselect.c: Prevent Glib main loop recursion.
+ 
  2013-12-08  Paul Eggert  <eggert@cs.ucla.edu>
  
  	Use libcrypto's checksum implementations if available, for speed.

=== modified file 'src/keyboard.c'
*** src/keyboard.c	2013-12-07 23:04:10 +0000
--- src/keyboard.c	2013-12-08 15:20:00 +0000
*************** unblock_input_to (int level)
*** 7118,7124 ****
  /* End critical section.
  
     If doing signal-driven input, and a signal came in when input was
!    blocked, reinvoke the signal handler now to deal with it.  */
  
  void
  unblock_input (void)
--- 7118,7129 ----
  /* End critical section.
  
     If doing signal-driven input, and a signal came in when input was
!    blocked, reinvoke the signal handler now to deal with it.
! 
!    It will also process queued input, if it was not read before.
!    When a longer code sequence does not use block/unblock input
!    at all, the whole input gathered up to the next call to
!    unblock_input will be processed inside that call. */
  
  void
  unblock_input (void)

=== modified file 'src/xgselect.c'
*** src/xgselect.c	2013-08-27 19:36:28 +0000
--- src/xgselect.c	2013-12-08 15:52:28 +0000
*************** along with GNU Emacs.  If not, see <http
*** 28,33 ****
--- 28,44 ----
  #include <timespec.h>
  #include "frame.h"
  
+ /* xg_select is a pselect replacement. Why do we need a separate function?
+    1. Timeouts. Glib and Gtk rely on timer events. If we did pselect
+       with a greater timeout then the one scheduled by Glib, we would
+       not allow Glib to process its timer events. We want Glib to
+       work smoothly, so we need to reduce our timeout to match Glib.
+    2. Descriptors. Glib may listen to more file descriptors than we do.
+       So we add Glib descriptors to our pselect pool, but we don't change
+       the value returned by the function. The return value  matches only
+       the descriptors passed as arguments, making it compatible with
+       plain pselect. */
+ 
  int
  xg_select (int fds_lim, fd_set *rfds, fd_set *wfds, fd_set *efds,
  	   struct timespec const *timeout, sigset_t const *sigmask)
*************** xg_select (int fds_lim, fd_set *rfds, fd
*** 45,56 ****
    int i, nfds, tmo_in_millisec;
    USE_SAFE_ALLOCA;
  
-   /* 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 ();
  
    if (rfds) all_rfds = *rfds;
--- 56,61 ----
*************** xg_select (int fds_lim, fd_set *rfds, fd
*** 132,139 ****
--- 137,149 ----
  #ifdef USE_GTK
        if (retval == 0)
  #endif
+         /* Prevent g_main_dispatch recursion, that would occur without
+            block_input wrapper, because event handlers call
+            unblock_input. Event loop recursion was causing Bug#15801. */
+         block_input();
          while (g_main_context_pending (context))
            g_main_context_dispatch (context);
+         unblock_input();
  
        /* To not have to recalculate timeout, return like this.  */
        if (retval == 0)

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jarek Czekalski]

[-- Attachment #1: Type: text/plain, Size: 72 bytes --]

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


[-- Attachment #2: scroll_freeze_2_1.txt --]
[-- Type: text/plain, Size: 3607 bytes --]

=== modified file 'src/ChangeLog'
*** src/ChangeLog	2013-12-08 08:05:36 +0000
--- src/ChangeLog	2013-12-08 16:00:41 +0000
***************
*** 1,3 ****
--- 1,9 ----
+ 2013-12-08  Jarek Czekalski  <jarekczek@poczta.onet.pl>
+ 
+ 	Fix freezing with scroll bars of GTK3 Toolkit (Bug#15801).
+ 	* keyboard.c: A comment to unblock_input.
+ 	* xgselect.c: Prevent Glib main loop recursion.
+ 
  2013-12-08  Paul Eggert  <eggert@cs.ucla.edu>
  
  	Use libcrypto's checksum implementations if available, for speed.

=== modified file 'src/keyboard.c'
*** src/keyboard.c	2013-12-07 23:04:10 +0000
--- src/keyboard.c	2013-12-08 15:20:00 +0000
*************** unblock_input_to (int level)
*** 7118,7124 ****
  /* End critical section.
  
     If doing signal-driven input, and a signal came in when input was
!    blocked, reinvoke the signal handler now to deal with it.  */
  
  void
  unblock_input (void)
--- 7118,7129 ----
  /* End critical section.
  
     If doing signal-driven input, and a signal came in when input was
!    blocked, reinvoke the signal handler now to deal with it.
! 
!    It will also process queued input, if it was not read before.
!    When a longer code sequence does not use block/unblock input
!    at all, the whole input gathered up to the next call to
!    unblock_input will be processed inside that call. */
  
  void
  unblock_input (void)

=== modified file 'src/xgselect.c'
*** src/xgselect.c	2013-08-27 19:36:28 +0000
--- src/xgselect.c	2013-12-08 22:54:04 +0000
*************** along with GNU Emacs.  If not, see <http
*** 27,32 ****
--- 27,44 ----
  #include <errno.h>
  #include <timespec.h>
  #include "frame.h"
+ #include "blockinput.h"
+ 
+ /* xg_select is a pselect replacement. Why do we need a separate function?
+    1. Timeouts. Glib and Gtk rely on timer events. If we did pselect
+       with a greater timeout then the one scheduled by Glib, we would
+       not allow Glib to process its timer events. We want Glib to
+       work smoothly, so we need to reduce our timeout to match Glib.
+    2. Descriptors. Glib may listen to more file descriptors than we do.
+       So we add Glib descriptors to our pselect pool, but we don't change
+       the value returned by the function. The return value  matches only
+       the descriptors passed as arguments, making it compatible with
+       plain pselect. */
  
  int
  xg_select (int fds_lim, fd_set *rfds, fd_set *wfds, fd_set *efds,
*************** xg_select (int fds_lim, fd_set *rfds, fd
*** 45,56 ****
    int i, nfds, tmo_in_millisec;
    USE_SAFE_ALLOCA;
  
-   /* 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 ();
  
    if (rfds) all_rfds = *rfds;
--- 57,62 ----
*************** xg_select (int fds_lim, fd_set *rfds, fd
*** 132,139 ****
--- 138,150 ----
  #ifdef USE_GTK
        if (retval == 0)
  #endif
+         /* Prevent g_main_dispatch recursion, that would occur without
+            block_input wrapper, because event handlers call
+            unblock_input. Event loop recursion was causing Bug#15801. */
+         block_input();
          while (g_main_context_pending (context))
            g_main_context_dispatch (context);
+         unblock_input();
  
        /* To not have to recalculate timeout, return like this.  */
        if (retval == 0)

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jan Djärv]

Hello.

9 dec 2013 kl. 00:29 skrev Jarek Czekalski <jarekczek@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.

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jarek Czekalski]

My Emacs assignment is filed in FSF under number 866994.

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Eli Zaretskii]

> Date: Fri, 20 Dec 2013 07:32:15 +0100
> From: Jarek Czekalski <jarekczek@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.

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Jarek Czekalski]

[-- Attachment #1: Type: text/plain, Size: 27 bytes --]

Patch rebased for r117003.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: scroll_freeze_2_1_r117003.patch --]
[-- Type: text/x-diff; name="scroll_freeze_2_1_r117003.patch", Size: 3685 bytes --]

=== modified file 'src/ChangeLog'
*** src/ChangeLog	2014-04-19 20:32:05 +0000
--- src/ChangeLog	2014-04-21 10:32:13 +0000
***************
*** 2448,2453 ****
--- 2448,2459 ----
  
  	* alloc.c (Fmemory_limit): Avoid compiler warning.  Return 0 always.
  
+ 2013-12-08  Jarek Czekalski  <jarekczek@poczta.onet.pl>
+ 
+ 	Fix freezing with scroll bars of GTK3 Toolkit (Bug#15801).
+ 	* keyboard.c: A comment to unblock_input.
+ 	* xgselect.c: Prevent Glib main loop recursion.
+ 
  2013-12-08  Jan Djärv  <jan.h.d@swipnet.se>
  
  	* nsterm.m (updateFrameSize:): Fix GNUstep toolbar not updating.

=== modified file 'src/keyboard.c'
*** src/keyboard.c	2014-04-16 19:43:46 +0000
--- src/keyboard.c	2014-04-21 10:32:13 +0000
***************
*** 7117,7123 ****
  /* End critical section.
  
     If doing signal-driven input, and a signal came in when input was
!    blocked, reinvoke the signal handler now to deal with it.  */
  
  void
  unblock_input (void)
--- 7117,7128 ----
  /* End critical section.
  
     If doing signal-driven input, and a signal came in when input was
!    blocked, reinvoke the signal handler now to deal with it.
! 
!    It will also process queued input, if it was not read before.
!    When a longer code sequence does not use block/unblock input
!    at all, the whole input gathered up to the next call to
!    unblock_input will be processed inside that call. */
  
  void
  unblock_input (void)

=== modified file 'src/xgselect.c'
*** src/xgselect.c	2014-04-16 19:43:46 +0000
--- src/xgselect.c	2014-04-21 10:32:13 +0000
***************
*** 28,33 ****
--- 28,45 ----
  #include <stdbool.h>
  #include <timespec.h>
  #include "frame.h"
+ #include "blockinput.h"
+ 
+ /* xg_select is a pselect replacement. Why do we need a separate function?
+    1. Timeouts. Glib and Gtk rely on timer events. If we did pselect
+       with a greater timeout then the one scheduled by Glib, we would
+       not allow Glib to process its timer events. We want Glib to
+       work smoothly, so we need to reduce our timeout to match Glib.
+    2. Descriptors. Glib may listen to more file descriptors than we do.
+       So we add Glib descriptors to our pselect pool, but we don't change
+       the value returned by the function. The return value  matches only
+       the descriptors passed as arguments, making it compatible with
+       plain pselect. */
  
  int
  xg_select (int fds_lim, fd_set *rfds, fd_set *wfds, fd_set *efds,
***************
*** 47,58 ****
    bool need_to_dispatch;
    USE_SAFE_ALLOCA;
  
-   /* 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 ();
  
    if (rfds) all_rfds = *rfds;
--- 59,64 ----
***************
*** 136,143 ****
    if (need_to_dispatch)
      {
        int pselect_errno = errno;
        while (g_main_context_pending (context))
! 	g_main_context_dispatch (context);
        errno = pselect_errno;
      }
  
--- 142,154 ----
    if (need_to_dispatch)
      {
        int pselect_errno = errno;
+       /* Prevent g_main_dispatch recursion, that would occur without
+          block_input wrapper, because event handlers call
+          unblock_input. Event loop recursion was causing Bug#15801. */
+       block_input();
        while (g_main_context_pending (context))
!         g_main_context_dispatch (context);
!       unblock_input();
        errno = pselect_errno;
      }
  

bug#15801: 24.3.50; bar scrolling freezes gtk emacs

[Stefan Monnier]

> Patch rebased for r117003.

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


        Stefan