bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Ashish SHUKLA]

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


1. Start: emacs -Q
2. Start emacs server: M-x server-start
3. In an xterm instance (in my case TERM=xterm-256color), do: emacsclient -t
4. In emacsclient session, do C-x C-f to get a 'Find file:' prompt.
5. Now I see emacsclient session started flickering with following 'truss' output:

#v+
sigprocmask(SIG_SETMASK,SIGINT|SIGQUIT|SIGALRM|SIGCHLD|SIGIO|SIGPROF|SIGWINCH,0x0) = 0 (0x0)
sigreturn(0x7fffffff62b0,0x7fffffff62b0,0x14f6000,0x0,0xfffffffffffffbd0,0x3) = 1 (0x1)
read(3,"\^A\0\M-g\M-n\0\0\0\0y"\M^@\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",4096) = 32 (0x20)
read(3,0x149d02c,4096)                           ERR#35 'Resource temporarily unavailable'
read(3,0x149d02c,4096)                           ERR#35 'Resource temporarily unavailable'
ioctl(20,FIONREAD,0xffff5bcc)                    = 0 (0x0)
read(3,0x149d02c,4096)                           ERR#35 'Resource temporarily unavailable'
poll({4/POLLIN 3/POLLIN 10/POLLIN|POLLPRI 12/POLLIN|POLLPRI 13/POLLIN|POLLPRI 14/POLLIN|POLLPRI},6,0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGALRM,0x0)               = 0 (0x0)
clock_gettime(0,{1362336835.762170496 })         = 0 (0x0)
ktimer_settime(0x3,0x0,0x7fffffff6bc0,0x0,0x1,0x0) = 0 (0x0)
sigprocmask(SIG_UNBLOCK,SIGALRM,0x0)             = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGIO|SIGWINCH,0x0)        = 0 (0x0)
write(20,"\r\^[[?25l\^[[38;5;20mFind file: \^[[39;49m~/\^[[K\^[[H\^[[7mFile Edit Options Buffers Tools Minibuf Help                                                                   \^[[0m\^[[39;49m\^[[27m\r\n\^[[A",181) = 181 (0xb5)
write(20,"\n\^[[38;5;124m;; This buffer is for notes you don't want to save, and for Lisp evaluation.                                   \^[[39;49m\r\n\^[[A\n\^[[38;5;124m;; If you want to create a file, visit that file with C-x C-f,                                                 \^[[39;49m\r\n\^[[A\n\^[[38;5;124m;; then enter the text in that file's own buffer.                                                              \^[[39;49m\r\n\^[[A\n\^[[K\n\^[[K",416) = 416 (0x1a0)
write(20,"\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K",40) = 40 (0x28)
write(20,"\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[30m\^[[48;5;250m-UUU:@----F2  \^[[39;49m\^[[1m\^[[30m\^[[48;5;250m*scratch*   \^[[0m\^[[39;49m\^[[30m\^[[48;5;250m   All L5     (Lisp Interaction) ----------------------------------------------------\^[[39;49m\r\n\^[[A\^[[24;14H\^[[?12l\^[[?25h\^[[?12;25h",250) = 250 (0xfa)
sigprocmask(SIG_BLOCK,SIGIO|SIGWINCH,0x0)        = 0 (0x0)
sigprocmask(SIG_UNBLOCK,SIGIO|SIGWINCH,0x0)      = 0 (0x0)
poll({3/POLLIN|POLLOUT},1,-1)                    = 1 (0x1)
writev(0x3,0x7fffffff8ec0,0x3,0x0,0x0,0x0)       = 56 (0x38)
SIGNAL 23 (SIGIO)
sigprocmask(SIG_SETMASK,SIGINT|SIGQUIT|SIGALRM|SIGCHLD|SIGIO|SIGPROF|SIGWINCH,0x0) = 0 (0x0)
sigreturn(0x7fffffff8510,0x7fffffff8510,0x14f6000,0x0,0xfffffffffffffbd0,0x0) = 56 (0x38)
read(3,0x149d02c,4096)                           ERR#35 'Resource temporarily unavailable'
poll({4/POLLIN 3/POLLIN 10/POLLIN|POLLPRI 12/POLLIN|POLLPRI 13/POLLIN|POLLPRI 14/POLLIN|POLLPRI},6,0) = 0 (0x0)
pselect(0x15,0x7fffffff9850,0x7fffffff97d0,0x0,0x7fffffff98f0,0x0) = 0 (0x0)
ioctl(20,FIONREAD,0xffff822c)                    = 0 (0x0)
read(3,0x149d02c,4096)                           ERR#35 'Resource temporarily unavailable'
poll({4/POLLIN 3/POLLIN 10/POLLIN|POLLPRI 12/POLLIN|POLLPRI 13/POLLIN|POLLPRI 14/POLLIN|POLLPRI},6,0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGALRM,0x0)               = 0 (0x0)
clock_gettime(0,{1362336835.763709872 })         = 0 (0x0)
ktimer_settime(0x3,0x0,0x7fffffff9220,0x0,0x1,0x0) = 0 (0x0)
sigprocmask(SIG_UNBLOCK,SIGALRM,0x0)             = 0 (0x0)
clock_gettime(0,{1362336835.763777908 })         = 0 (0x0)
clock_gettime(0,{1362336835.763798417 })         = 0 (0x0)
clock_gettime(0,{1362336835.763817197 })         = 0 (0x0)
poll({3/POLLIN|POLLOUT},1,-1)                    = 1 (0x1)
writev(0x3,0x7fffffff6bc0,0x3,0x0,0x0,0x0)       = 8 (0x8)
poll({3/POLLIN},1,-1)                            ERR#4 'Interrupted system call'
SIGNAL 23 (SIGIO)
SIGNAL 23 (SIGIO)
sigprocmask(SIG_SETMASK,SIGINT|SIGQUIT|SIGALRM|SIGCHLD|SIGIO|SIGPROF|SIGWINCH,0x0) = 0 (0x0)
sigprocmask(SIG_SETMASK,SIGINT|SIGQUIT|SIGALRM|SIGCHLD|SIGIO|SIGPROF|SIGWINCH,0x0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGIO,0x0)                 = 0 (0x0)
sigreturn(0x7fffffff62b0,0x7fffffff62b0,0x14f6000,0x0,0xfffffffffffffbd0,0x3) = 1 (0x1)
SIGNAL 23 (SIGIO)
sigreturn(0x7fffffbfd640,0x7fffffbfd640,0x14f6000,0x0,0xfffffffffffffbd0,0x0) ERR#4 'Interrupted system call'
poll({7/POLLIN 15/POLLIN 18/POLLIN},3,-1)        = 0 (0x0)
sigreturn(0x7fffffff62b0,0x7fffffff62b0,0x14f6000,0x0,0xfffffffffffffbd0,0x3) = 1 (0x1)
read(3,"\^A\0\M-k\M-n\0\0\0\0y"\M^@\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",4096) = 32 (0x20)
read(3,0x149d02c,4096)                           ERR#35 'Resource temporarily unavailable'
read(3,0x149d02c,4096)                           ERR#35 'Resource temporarily unavailable'
ioctl(20,FIONREAD,0xffff5bcc)                    = 0 (0x0)
read(3,0x149d02c,4096)                           ERR#35 'Resource temporarily unavailable'
poll({4/POLLIN 3/POLLIN 10/POLLIN|POLLPRI 12/POLLIN|POLLPRI 13/POLLIN|POLLPRI 14/POLLIN|POLLPRI},6,0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGALRM,0x0)               = 0 (0x0)
clock_gettime(0,{1362336835.766920001 })         = 0 (0x0)
ktimer_settime(0x3,0x0,0x7fffffff6bc0,0x0,0x1,0x0) = 0 (0x0)
sigprocmask(SIG_UNBLOCK,SIGALRM,0x0)             = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGIO|SIGWINCH,0x0)        = 0 (0x0)
write(20,"\r\^[[?25l\^[[38;5;20mFind file: \^[[39;49m~/\^[[K\^[[H\^[[7mFile Edit Options Buffers Tools Minibuf Help                                                                   \^[[0m\^[[39;49m\^[[27m\r\n\^[[A",181) = 181 (0xb5)
write(20,"\n\^[[38;5;124m;; This buffer is for notes you don't want to save, and for Lisp evaluation.                                   \^[[39;49m\r\n\^[[A\n\^[[38;5;124m;; If you want to create a file, visit that file with C-x C-f,                                                 \^[[39;49m\r\n\^[[A\n\^[[38;5;124m;; then enter the text in that file's own buffer.                                                              \^[[39;49m\r\n\^[[A\n\^[[K\n\^[[K",416) = 416 (0x1a0)
write(20,"\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K",40) = 40 (0x28)
write(20,"\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[30m\^[[48;5;250m-UUU:@----F2  \^[[39;49m\^[[1m\^[[30m\^[[48;5;250m*scratch*   \^[[0m\^[[39;49m\^[[30m\^[[48;5;250m   All L5     (Lisp Interaction) ----------------------------------------------------\^[[39;49m\r\n\^[[A\^[[24;14H\^[[?12l\^[[?25h\^[[?12;25h",250) = 250 (0xfa)
sigprocmask(SIG_BLOCK,SIGIO|SIGWINCH,0x0)        = 0 (0x0)
sigprocmask(SIG_UNBLOCK,SIGIO|SIGWINCH,0x0)      = 0 (0x0)
poll({3/POLLIN|POLLOUT},1,-1)                    = 1 (0x1)
writev(0x3,0x7fffffff8ec0,0x3,0x0,0x0,0x0)       = 56 (0x38)
read(3,0x149d02c,4096)                           ERR#35 'Resource temporarily unavailable'
poll({4/POLLIN 3/POLLIN 10/POLLIN|POLLPRI 12/POLLIN|POLLPRI 13/POLLIN|POLLPRI 14/POLLIN|POLLPRI},6,0) = 0 (0x0)
pselect(0x15,0x7fffffff9850,0x7fffffff97d0,0x0,0x7fffffff98f0,0x0) ERR#4 'Interrupted system call'
SIGNAL 23 (SIGIO)
sigprocmask(SIG_SETMASK,SIGINT|SIGQUIT|SIGALRM|SIGCHLD|SIGIO|SIGPROF|SIGWINCH,0x0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGIO,0x0)                 = 0 (0x0)
thr_kill(0x18841,0x17,0x1,0x0,0x5647f0,0x0)      ERR#4 'Interrupted system call'
SIGNAL 23 (SIGIO)
sigprocmask(SIG_SETMASK,SIGINT|SIGQUIT|SIGALRM|SIGCHLD|SIGIO|SIGPROF|SIGWINCH,0x0) = 0 (0x0)
sigreturn(0x7fffffbfd640,0x7fffffbfd640,0x14f6000,0x0,0xfffffffffffffbd0,0x0) ERR#4 'Interrupted system call'
poll({7/POLLIN 15/POLLIN 18/POLLIN},3,-1)        ERR#4 'Interrupted system call'
ioctl(20,FIONREAD,0xffff822c)                    = 0 (0x0)
read(3,0x149d02c,4096)                           ERR#35 'Resource temporarily unavailable'
poll({4/POLLIN 3/POLLIN 10/POLLIN|POLLPRI 12/POLLIN|POLLPRI 13/POLLIN|POLLPRI 14/POLLIN|POLLPRI},6,0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGALRM,0x0)               = 0 (0x0)
clock_gettime(0,{1362336835.769231248 })         = 0 (0x0)
ktimer_settime(0x3,0x0,0x7fffffff9220,0x0,0x1,0x0) = 0 (0x0)
sigprocmask(SIG_UNBLOCK,SIGALRM,0x0)             = 0 (0x0)
clock_gettime(0,{1362336835.769299284 })         = 0 (0x0)
clock_gettime(0,{1362336835.769319712 })         = 0 (0x0)
clock_gettime(0,{1362336835.769338739 })         = 0 (0x0)
poll({3/POLLIN|POLLOUT},1,-1)                    = 1 (0x1)
writev(0x3,0x7fffffff6bc0,0x3,0x0,0x0,0x0)       = 8 (0x8)
poll({3/POLLIN},1,-1)                            ERR#4 'Interrupted system call'
SIGNAL 23 (SIGIO)
SIGNAL 23 (SIGIO)
sigprocmask(SIG_SETMASK,SIGINT|SIGQUIT|SIGALRM|SIGCHLD|SIGIO|SIGPROF|SIGWINCH,0x0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGIO,0x0)                 = 0 (0x0)
thr_kill(0x18841,0x17,0x1,0x0,0x5647f0,0x0)      = 0 (0x0)
sigreturn(0x7fffffff62b0,0x7fffffff62b0,0x14f6000,0x0,0xfffffffffffffbd0,0x3) = 1 (0x1)
SIGNAL 23 (SIGIO)
sigreturn(0x7fffffbfd640,0x7fffffbfd640,0x14f6000,0x0,0xfffffffffffffbd0,0x0) ERR#4 'Interrupted system call'
sigprocmask(SIG_SETMASK,SIGINT|SIGQUIT|SIGALRM|SIGCHLD|SIGIO|SIGPROF|SIGWINCH,0x0) = 0 (0x0)
sigreturn(0x7fffffff62b0,0x7fffffff62b0,0x14f6000,0x0,0xfffffffffffffbd0,0x3) = 1 (0x1)
read(3,"\^A\0\M-o\M-n\0\0\0\0y"\M^@\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",4096) = 32 (0x20)
read(3,0x149d02c,4096)                           ERR#35 'Resource temporarily unavailable'
read(3,0x149d02c,4096)                           ERR#35 'Resource temporarily unavailable'
ioctl(20,FIONREAD,0xffff5bcc)                    = 0 (0x0)
read(3,0x149d02c,4096)                           ERR#35 'Resource temporarily unavailable'
poll({4/POLLIN 3/POLLIN 10/POLLIN|POLLPRI 12/POLLIN|POLLPRI 13/POLLIN|POLLPRI 14/POLLIN|POLLPRI},6,0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGALRM,0x0)               = 0 (0x0)
clock_gettime(0,{1362336835.770651273 })         = 0 (0x0)
ktimer_settime(0x3,0x0,0x7fffffff6bc0,0x0,0x1,0x0) = 0 (0x0)
sigprocmask(SIG_UNBLOCK,SIGALRM,0x0)             = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGIO|SIGWINCH,0x0)        = 0 (0x0)
write(20,"\r\^[[?25l\^[[38;5;20mFind file: \^[[39;49m~/\^[[K\^[[H\^[[7mFile Edit Options Buffers Tools Minibuf Help                                                                   \^[[0m\^[[39;49m\^[[27m\r\n\^[[A",181) = 181 (0xb5)
write(20,"\n\^[[38;5;124m;; This buffer is for notes you don't want to save, and for Lisp evaluation.                                   \^[[39;49m\r\n\^[[A\n\^[[38;5;124m;; If you want to create a file, visit that file with C-x C-f,                                                 \^[[39;49m\r\n\^[[A\n\^[[38;5;124m;; then enter the text in that file's own buffer.                                                              \^[[39;49m\r\n\^[[A\n\^[[K\n\^[[K",416) = 416 (0x1a0)
write(20,"\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K",40) = 40 (0x28)
write(20,"\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[K\n\^[[30m\^[[48;5;250m-UUU:@----F2  \^[[39;49m\^[[1m\^[[30m\^[[48;5;250m*scratch*   \^[[0m\^[[39;49m\^[[30m\^[[48;5;250m   All L5     (Lisp Interaction) ----------------------------------------------------\^[[39;49m\r\n\^[[A\^[[24;14H\^[[?12l\^[[?25h\^[[?12;25h",250) = 250 (0xfa)
sigprocmask(SIG_BLOCK,SIGIO|SIGWINCH,0x0)        = 0 (0x0)
sigprocmask(SIG_UNBLOCK,SIGIO|SIGWINCH,0x0)      = 0 (0x0)
poll({3/POLLIN|POLLOUT},1,-1)                    = 1 (0x1)
writev(0x3,0x7fffffff8ec0,0x3,0x0,0x0,0x0)       = 56 (0x38)
read(3,0x149d02c,4096)                           ERR#35 'Resource temporarily unavailable'
poll({4/POLLIN 3/POLLIN 10/POLLIN|POLLPRI 12/POLLIN|POLLPRI 13/POLLIN|POLLPRI 14/POLLIN|POLLPRI},6,0) = 0 (0x0)
pselect(0x15,0x7fffffff9850,0x7fffffff97d0,0x0,0x7fffffff98f0,0x0) ERR#4 'Interrupted system call'
SIGNAL 23 (SIGIO)
sigprocmask(SIG_SETMASK,SIGINT|SIGQUIT|SIGALRM|SIGCHLD|SIGIO|SIGPROF|SIGWINCH,0x0) = 0 (0x0)
#v-

Buffer in original Emacs X11 frame is displaying *Messages* atm, whereas
buffer in emacsclient session is displaying *scratch* buffer atm. But it
happens even if they're displaying same buffer.

It doesn't happen when I open a file (I tried with text mode, c-mode)
iin emacsclient session, via command-line: emacsclient -t
~/code/emacs/src/xterm.c .  But flickering starts to happen when I focus
to X11 frame (just click in X11 frame) and then focus back to
emacsclient session (clicking in xterm window), and press any key. When
I do C-g in emacsclient session, flickering stops.

Above steps are with 'emacs -Q', so I don't think there is any problem
with my $HOME/.emacs.d/init.el .




In GNU Emacs 24.3.50.1 (amd64-portbld-freebsd9.1, GTK+ Version 3.0.12)
 of 2013-03-03 on chateau.d.if
Windowing system distributor `The X.Org Foundation', version 11.0.11006000
Configured using:
 `configure --localstatedir=/var --with-x-toolkit=gtk3 --with-xft
 --with-m17n-flt --with-libotf --with-imagemagick --with-gsettings
 --with-gconf --with-xim --with-sound --with-dbus --with-xml2
 --with-gnutls --with-acl --x-libraries=/usr/local/lib
 --x-includes=/usr/local/include --prefix=/usr/local
 --mandir=/usr/local/man --infodir=/usr/local/info/
 --build=amd64-portbld-freebsd9.1 CFLAGS='-fstack-protector -g'
 CPPFLAGS='-I/usr/local/include' LDFLAGS=' -L/usr/local/lib
 -Wl,-rpath=/usr/local/lib''

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  shell-dirtrack-mode: t
  global-auto-complete-mode: t
  auto-complete-mode: t
  delete-selection-mode: t
  display-time-mode: t
  show-paren-mode: t
  tooltip-mode: t
  mouse-wheel-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
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-x 1 M-x m <backspace> e m <tab> a <tab> c <backspace> 
<backspace> - r e <tab> <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
r e p <tab> r <backspace> o r t - m <tab> <backspace> 
e m <tab> <return>

Recent messages:
Function slime-forward-cruft is already compiled
Function slime-forward-reader-conditional is already compiled
../../../.emacs.d/elisp/slime/contrib/slime-repl.el: `flet' is an obsolete macro (as of 24.3); use either `cl-flet' or `cl-letf'. [2 times]
../../../.emacs.d/elisp/auto-complete/auto-complete.el: `flet' is an obsolete macro (as of 24.3); use either `cl-flet' or `cl-letf'.
Loading /home/abbe/.emacs.d/.blog.el (source)...
../../../.emacs.d/elisp/xml-rpc.el: (lambda (p) ...) quoted with ' rather than with #'
Loading /home/abbe/.emacs.d/.blog.el (source)...done
Loading ~/.emacs.d/elisp/785600/toggle-root...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list... [2 times]

Load-path shadows:
/home/abbe/.emacs.d/elisp/apel/env hides /usr/local/share/emacs/24.3.50/lisp/env
/home/abbe/.emacs.d/elisp/apel/timezone hides /usr/local/share/emacs/24.3.50/lisp/timezone
/home/abbe/.emacs.d/elisp/full-ack/.dir-locals hides /usr/local/share/emacs/24.3.50/lisp/gnus/.dir-locals

Features:
(shadow sort hashcash mail-extr emacsbug message idna rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader sendmail
mail-utils help-mode server deeper-blue-theme tramp tramp-compat
tramp-loaddefs trampver shell geiser blog metaweblog xml-rpc timezone
url-http tls url url-proxy url-privacy url-expand url-methods
url-history mailcap url-auth mail-parse rfc2231 rfc2047 rfc2045
ietf-drums url-cookie url-domsuf url-util url-parse auth-source eieio
gnus-util mm-util mail-prsvr password-cache url-gw url-vars xml
muse-html muse-xml-common cus-edit cus-start cus-load muse-publish
muse-project muse-protocols info muse-regexps wid-edit derived muse
muse-nested-tags muse-mode org-agenda org ob-tangle ob-ref ob-lob
ob-table org-footnote org-src ob-comint ob-keys org-pcomplete pcomplete
org-list org-faces org-entities noutline outline org-version
ob-emacs-lisp ob org-compat org-macs ob-eval org-loaddefs format-spec
find-func cal-menu calendar cal-loaddefs auto-complete-config
auto-complete popup slime-repl byte-opt elp slime warnings bytecomp
byte-compile cconv easy-mmode hideshow easymenu pp comint ansi-color
ring hyperspec thingatpt browse-url clojure-mode edmacro kmacro
scim-bridge mule-util advice help-fns alist pym static apel-ver product
elscreen bbdb-autoloads w3m-load erlang-start boxquote cl-macs gv rect
cl cl-lib delsel time paren uniquify nadvice go-mode-load 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
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 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
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty emacs)

Please let me know if you need more information.

Thanks
-- 
Ashish SHUKLA

Sent via Gnus from GNU Emacs

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Eli Zaretskii]

> From: Ashish SHUKLA <ashish.is@lostca.se>
> Date: Mon, 04 Mar 2013 00:49:47 +0530
> 
> 1. Start: emacs -Q
> 2. Start emacs server: M-x server-start
> 3. In an xterm instance (in my case TERM=xterm-256color), do: emacsclient -t
> 4. In emacsclient session, do C-x C-f to get a 'Find file:' prompt.
> 5. Now I see emacsclient session started flickering with following 'truss' output:

Thanks.  Unfortunately, I seem to be unable to reproduce this with the
Emacs configurations to which I have access.  One thing I couldn't try
was a GUI session that also has a TTY frame created by "emacsclient -t",
I could only try a TTY session in which another TTY frame on a
different terminal was created by emacsclient.  Maybe this is the
crucial difference: do you see the same problem when Emacs that runs
the server is started with -nw?

Did this problem appear lately, or do you see it in previous versions
as well (e.g., on the emacs-24 branch)?  If this only appeared
recently, could you perhaps bisect to find the commit which caused
this?

Also, would you be ready to run Emacs under a debugger and look around
where I suggest you to?

Thanks.

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Ashish SHUKLA]

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

On Mon, 04 Mar 2013 19:50:10 +0200, Eli Zaretskii <eliz@gnu.org> said:
>> From: Ashish SHUKLA <ashish.is@lostca.se>
>> Date: Mon, 04 Mar 2013 00:49:47 +0530
>> 
>> 1. Start: emacs -Q
>> 2. Start emacs server: M-x server-start
>> 3. In an xterm instance (in my case TERM=xterm-256color), do: emacsclient -t
>> 4. In emacsclient session, do C-x C-f to get a 'Find file:' prompt.
>> 5. Now I see emacsclient session started flickering with following 'truss' output:

> Thanks.  Unfortunately, I seem to be unable to reproduce this with the
> Emacs configurations to which I have access.  One thing I couldn't try
> was a GUI session that also has a TTY frame created by "emacsclient -t",
> I could only try a TTY session in which another TTY frame on a
> different terminal was created by emacsclient.  Maybe this is the
> crucial difference: do you see the same problem when Emacs that runs
> the server is started with -nw?

It doesn't happen with 'emacs -nw', only with X11.

> Did this problem appear lately, or do you see it in previous versions
> as well (e.g., on the emacs-24 branch)?  If this only appeared
> recently, could you perhaps bisect to find the commit which caused
> this?

As, I only recently started to use Emacs like this, it became noticeable, but
I don't remember encountering it before when multi-tty support was introduced.

I've couple of old Emacs 24.3.50, and Emacs ~23.x packages. I can give them a
shot.

> Also, would you be ready to run Emacs under a debugger and look around
> where I suggest you to?

Sure.

Thanks
-- 
Ashish SHUKLA

“They that give up essential liberty to obtain a little temporary safety deserve
neither liberty nor safety.” (Benjamin Franklin)

Sent from my Emacs

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Eli Zaretskii]

> From: ashish.is@lostca.se (Ashish SHUKLA)
> Cc: 13864@debbugs.gnu.org
> Date: Tue, 05 Mar 2013 00:43:11 +0530
> 
> > Did this problem appear lately, or do you see it in previous versions
> > as well (e.g., on the emacs-24 branch)?  If this only appeared
> > recently, could you perhaps bisect to find the commit which caused
> > this?
> 
> As, I only recently started to use Emacs like this, it became noticeable, but
> I don't remember encountering it before when multi-tty support was introduced.
> 
> I've couple of old Emacs 24.3.50, and Emacs ~23.x packages. I can give them a
> shot.

Please do.

> > Also, would you be ready to run Emacs under a debugger and look around
> > where I suggest you to?
> 
> Sure.

Thanks.  Let's see what you find with older versions first.

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Ashish SHUKLA]

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

On Mon, 04 Mar 2013 22:22:30 +0200, Eli Zaretskii <eliz@gnu.org> said:
>> From: ashish.is@lostca.se (Ashish SHUKLA)
>> Cc: 13864@debbugs.gnu.org
>> Date: Tue, 05 Mar 2013 00:43:11 +0530
>> 
>> > Did this problem appear lately, or do you see it in previous versions
>> > as well (e.g., on the emacs-24 branch)?  If this only appeared
>> > recently, could you perhaps bisect to find the commit which caused
>> > this?
>> 
>> As, I only recently started to use Emacs like this, it became noticeable, but
>> I don't remember encountering it before when multi-tty support was introduced.
>> 
>> I've couple of old Emacs 24.3.50, and Emacs ~23.x packages. I can give them a
>> shot.

> Please do.

I tried r1110803, r110921, r111026, r111253, r111312, and r111607, they were
good.  Then, I tried r111818, and it has this.

No problem with Emacs 23.4.

HTH
-- 
Ashish SHUKLA

“Let others praise ancient times; I am glad I was born in these.” (Ovid (43 B.C. - A.D. 18))

Sent from my Emacs

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Eli Zaretskii]

> From: ashish.is@lostca.se (Ashish SHUKLA)
> Cc: 13864@debbugs.gnu.org
> Date: Tue, 05 Mar 2013 05:56:40 +0530
> 
> I tried r1110803, r110921, r111026, r111253, r111312, and r111607, they were
> good.  Then, I tried r111818, and it has this.
> 
> No problem with Emacs 23.4.

So this is a recent regression.  Thanks, this narrows down the set of
culprits quite a bit, but still not enough to see the root cause.

Could you please attach a debugger to Emacs, after starting the
server, but before opening the TTY frame with emacsclient, and set a
breakpoint like this:

 (gdb) break update_frame_1
 (gdb) commands
  > p force_p
  > p inhibit_id_p
  > continue
  > end
 (gdb)

Then re-create the problem and see whether update_frame_1 is called
very frequently, and if so, what are the values of the 2 arguments
printed by the breakpoint commands above.  (I don't know what is your
level of proficiency with GDB, so let me know if you need more
detailed instructions.)

Don't forget to invoke GDB from the src directory, and make sure that
it reads the .gdbinit file there, and does not reject it due to
security considerations.

If update_frame_1 indeed gets called at high frequency when the xterm
frame flickers, then please do the same when Emacs is started with -nw
(in which case I understand that there's no flickering), and see if
there's any difference in the frequency of calls to update_frame_1 and
in the values of the above 2 arguments.

TIA

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Ashish SHUKLA]

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

On Wed, 06 Mar 2013 19:07:36 +0200, Eli Zaretskii <eliz@gnu.org> said:
>> From: ashish.is@lostca.se (Ashish SHUKLA)
>> Cc: 13864@debbugs.gnu.org
>> Date: Tue, 05 Mar 2013 05:56:40 +0530
>> 
>> I tried r1110803, r110921, r111026, r111253, r111312, and r111607, they were
>> good.  Then, I tried r111818, and it has this.
>> 
>> No problem with Emacs 23.4.

> So this is a recent regression.  Thanks, this narrows down the set of
> culprits quite a bit, but still not enough to see the root cause.

> Could you please attach a debugger to Emacs, after starting the
> server, but before opening the TTY frame with emacsclient, and set a
> breakpoint like this:

>  (gdb) break update_frame_1
>  (gdb) commands
>> p force_p
>> p inhibit_id_p
>> continue
>> end
>  (gdb)

> Then re-create the problem and see whether update_frame_1 is called
> very frequently, and if so, what are the values of the 2 arguments
> printed by the breakpoint commands above.  (I don't know what is your
> level of proficiency with GDB, so let me know if you need more
> detailed instructions.)

> Don't forget to invoke GDB from the src directory, and make sure that
> it reads the .gdbinit file there, and does not reject it due to
> security considerations.

> If update_frame_1 indeed gets called at high frequency when the xterm
> frame flickers, then please do the same when Emacs is started with -nw
> (in which case I understand that there's no flickering), and see if
> there's any difference in the frequency of calls to update_frame_1 and
> in the values of the above 2 arguments.

Output with 'emacs -Q':

#v+
Breakpoint 3, update_frame_1 (f=0x1895d98, force_p=true, inhibit_id_p=false)
    at dispnew.c:4474
4474      struct glyph_matrix *current_matrix = f->current_matrix;
$85 = true
$86 = false

Breakpoint 3, update_frame_1 (f=0x1895d98, force_p=true, inhibit_id_p=false)
    at dispnew.c:4474
4474      struct glyph_matrix *current_matrix = f->current_matrix;
$87 = true
$88 = false

Breakpoint 3, update_frame_1 (f=0x1895d98, force_p=true, inhibit_id_p=false)
    at dispnew.c:4474
4474      struct glyph_matrix *current_matrix = f->current_matrix;
$89 = true
$90 = false
#v-

Output with 'emacs -Q -nw':

#v+
Breakpoint 3, update_frame_1 (f=0x1255c48, force_p=true, inhibit_id_p=false)
    at dispnew.c:4474
4474      struct glyph_matrix *current_matrix = f->current_matrix;
$39 = true
$40 = false

Breakpoint 3, update_frame_1 (f=0x1255c48, force_p=true, inhibit_id_p=false)
    at dispnew.c:4474
4474      struct glyph_matrix *current_matrix = f->current_matrix;
$41 = true
$42 = false

Breakpoint 3, update_frame_1 (f=0x1255c48, force_p=true, inhibit_id_p=false)
    at dispnew.c:4474
4474      struct glyph_matrix *current_matrix = f->current_matrix;
$43 = true
$44 = false
#v-

Output with 'emacs -Q' was more frequent, whereas output with 'emacs -Q -nw'
only printed when I pressed some key into the 'emacsclient' xterm window.

HTH
-- 
Ashish SHUKLA

“I am free, no matter what rules surround me. If I find them tolerable, I
tolerate them; if I find them too obnoxious, I break them. I am free because I
know that I alone am morally responsible for everything I do.” (Robert
A. Heinlein, "The Moon Is a Harsh Mistress", 1966)

Sent from my Emacs

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Eli Zaretskii]

> From: ashish.is@lostca.se (Ashish SHUKLA)
> Cc: 13864@debbugs.gnu.org
> Date: Thu, 07 Mar 2013 00:22:43 +0530
> 
> Output with 'emacs -Q' was more frequent, whereas output with 'emacs -Q -nw'
> only printed when I pressed some key into the 'emacsclient' xterm window.

So with "emacs -Q", you saw update_frame_1 being constantly called all
the time, even if you didn't press any key after "C-x C-f", is that
right?

If so, please add "bt" to the breakpoint commands, so that we see who
is calling update_frame_1.

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Ashish SHUKLA]

[-- Attachment #1.1: Type: text/plain, Size: 1039 bytes --]

On Wed, 06 Mar 2013 23:00:18 +0200, Eli Zaretskii <eliz@gnu.org> said:
>> From: ashish.is@lostca.se (Ashish SHUKLA)
>> Cc: 13864@debbugs.gnu.org
>> Date: Thu, 07 Mar 2013 00:22:43 +0530
>> 
>> Output with 'emacs -Q' was more frequent, whereas output with 'emacs
>> -Q -nw'
>> only printed when I pressed some key into the 'emacsclient' xterm
>> window.

> So with "emacs -Q", you saw update_frame_1 being constantly called all
> the time, even if you didn't press any key after "C-x C-f", is that
> right?

Correct.

> If so, please add "bt" to the breakpoint commands, so that we see who
> is calling update_frame_1.

Please find the gdb output in attached file, immediately after doing
"emacsclient -t .emacs.d/init.el". I didn't press any key, or did anything to
few window. After few pages of output I decided to exit from GDB.

HTH
-- 
Ashish SHUKLA

“Indians will believe anything told to them anyway. And besides for the
doubters, there's $%^#~@~~ CARRIER LOST” (Joseph Koshy)

Sent from my Emacs

[-- Attachment #1.2: emacs-output.txt.xz --]
[-- Type: application/octet-stream, Size: 3704 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Eli Zaretskii]

> From: ashish.is@lostca.se (Ashish SHUKLA)
> Cc: 13864@debbugs.gnu.org
> Date: Thu, 07 Mar 2013 07:13:46 +0530
> 
> > So with "emacs -Q", you saw update_frame_1 being constantly called all
> > the time, even if you didn't press any key after "C-x C-f", is that
> > right?
> 
> Correct.
> 
> > If so, please add "bt" to the breakpoint commands, so that we see who
> > is calling update_frame_1.
> 
> Please find the gdb output in attached file, immediately after doing
> "emacsclient -t .emacs.d/init.el". I didn't press any key, or did anything to
> few window. After few pages of output I decided to exit from GDB.

Thanks.  However, didn't you say that the flickering only starts once
you type "C-x C-f" in the frame open by emacsclient?  If so, I need
this GDB output after you type "C-x C-f", please.

And yes, once the backtrace and the values of the two arguments start
repeating themselves, you can exit GDB.

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Ashish SHUKLA]

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

On Thu, 07 Mar 2013 08:55:51 +0200, Eli Zaretskii <eliz@gnu.org> said:
>> From: ashish.is@lostca.se (Ashish SHUKLA)
>> Cc: 13864@debbugs.gnu.org
>> Date: Thu, 07 Mar 2013 07:13:46 +0530
>> 
>> > So with "emacs -Q", you saw update_frame_1 being constantly called all
>> > the time, even if you didn't press any key after "C-x C-f", is that
>> > right?
>> 
>> Correct.
>> 
>> > If so, please add "bt" to the breakpoint commands, so that we see who
>> > is calling update_frame_1.
>> 
>> Please find the gdb output in attached file, immediately after doing
>> "emacsclient -t .emacs.d/init.el". I didn't press any key, or did anything to
>> few window. After few pages of output I decided to exit from GDB.

> Thanks.  However, didn't you say that the flickering only starts once
> you type "C-x C-f" in the frame open by emacsclient?  If so, I need
> this GDB output after you type "C-x C-f", please.

Well, it happens:

 - if I press C-x C-f in 'emacsclient -t' xterm

OR

 - focus to X11 frame
 - focus back to 'emacsclient -t' xterm
 - press any key

> And yes, once the backtrace and the values of the two arguments start
> repeating themselves, you can exit GDB.

Okay. Do you know any way to prevent GDB from paging the output (i.e. printing
"press enter to continue message"), which becomes annoying when capturing a
streaming output like this ?

Thanks
-- 
Ashish SHUKLA

“At some point, bits have to go into packets and routers need to make decisions
on them. Changes at that level is what I want to hear about, not strategic
company relationships.” (John Carmack)

Sent from my Emacs

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Eli Zaretskii]

> From: ashish.is@lostca.se (Ashish SHUKLA)
> Cc: 13864@debbugs.gnu.org
> Date: Thu, 07 Mar 2013 13:08:49 +0530
> 
> > Thanks.  However, didn't you say that the flickering only starts once
> > you type "C-x C-f" in the frame open by emacsclient?  If so, I need
> > this GDB output after you type "C-x C-f", please.
> 
> Well, it happens:
> 
>  - if I press C-x C-f in 'emacsclient -t' xterm
> 
> OR
> 
>  - focus to X11 frame
>  - focus back to 'emacsclient -t' xterm
>  - press any key

And the output you sent was after one of these recipes?  If so, then
what you sent is all I need for now.

> Do you know any way to prevent GDB from paging the output
> (i.e. printing "press enter to continue message"), which becomes
> annoying when capturing a streaming output like this ?

Either

    (gdb) set pagination off
or
    (gdb) set height 0

will do that.

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Ashish SHUKLA]

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

On Thu, 07 Mar 2013 11:16:18 +0200, Eli Zaretskii <eliz@gnu.org> said:
>> From: ashish.is@lostca.se (Ashish SHUKLA)
>> Cc: 13864@debbugs.gnu.org
>> Date: Thu, 07 Mar 2013 13:08:49 +0530
>> 
>> > Thanks.  However, didn't you say that the flickering only starts once
>> > you type "C-x C-f" in the frame open by emacsclient?  If so, I need
>> > this GDB output after you type "C-x C-f", please.
>> 
>> Well, it happens:
>> 
>> - if I press C-x C-f in 'emacsclient -t' xterm
>> 
>> OR
>> 
>> - focus to X11 frame
>> - focus back to 'emacsclient -t' xterm
>> - press any key

> And the output you sent was after one of these recipes?  If so, then
> what you sent is all I need for now.

Right, the output where "redisplay_internal" was the only frame in the Lisp
backtrace is when it started flickering.

>> Do you know any way to prevent GDB from paging the output
>> (i.e. printing "press enter to continue message"), which becomes
>> annoying when capturing a streaming output like this ?

> Either

>     (gdb) set pagination off
> or
>     (gdb) set height 0

> will do that.

Thanks

Let me know if you need anything else or like me to test something.

Thanks
-- 
Ashish SHUKLA

“The wonderful thing about science is that it doesn't ask for your faith, it
just ask for your eyes.” (xkcd #154)

Sent from my Emacs

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Eli Zaretskii]

> From: ashish.is@lostca.se (Ashish SHUKLA)
> Cc: 13864@debbugs.gnu.org
> Date: Thu, 07 Mar 2013 15:49:55 +0530
> 
> >     (gdb) set pagination off
> > or
> >     (gdb) set height 0
> 
> > will do that.
> 
> Thanks
> 
> Let me know if you need anything else or like me to test something.

Another trick that potentially avoids some work is this:

 (gdb) set logging on

This will cause GDB to put all of its output on a file named gdb.txt,
so you don't need to copy-paste from your screen into the mail
messages.  (Caveat: this does not show what _you_ type at GDB's
prompt, only the GDB responses.)

What I need now is the output of several times the following
breakpoint is hit:

  (gdb) break dispnew.c:4509
  (gdb) commands
   > p i
   > p desired_matrix->nrows
   > if i < desired_matrix->nrows
    > pgrowx desired_matrix->rows+i
    > end
   > end

Also, let's see if scrolling_1 is ever called:

  (gdb) break scrolling_1
  (gdb) commands
   > continue
   > end
  (gdb)

The goal is to understand why Emacs is redrawing the display although
nothing on display changes.  There's some convoluted code in
update_frame_line, a subroutine of update_frame_1, which attempts to
find the differences between the current line on display and what
should be on the current line, and only redraw the part(s) that
changed.  I'd expect that code to figure out that nothing needs to be
redrawn in this case, but somehow it fails, I don't yet see why.

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Ashish SHUKLA]

[-- Attachment #1.1: Type: text/plain, Size: 2634 bytes --]

On Thu, 07 Mar 2013 14:48:20 +0200, Eli Zaretskii <eliz@gnu.org> said:
>> From: ashish.is@lostca.se (Ashish SHUKLA)
>> Cc: 13864@debbugs.gnu.org
>> Date: Thu, 07 Mar 2013 15:49:55 +0530
>> 
>> >     (gdb) set pagination off
>> > or
>> >     (gdb) set height 0
>> 
>> > will do that.
>> 
>> Thanks
>> 
>> Let me know if you need anything else or like me to test something.

> Another trick that potentially avoids some work is this:

>  (gdb) set logging on

> This will cause GDB to put all of its output on a file named gdb.txt,
> so you don't need to copy-paste from your screen into the mail
> messages.  (Caveat: this does not show what _you_ type at GDB's
> prompt, only the GDB responses.)

> What I need now is the output of several times the following
> breakpoint is hit:

>   (gdb) break dispnew.c:4509
>   (gdb) commands
>> p i
>> p desired_matrix->nrows
>> if i < desired_matrix->nrows
>> pgrowx desired_matrix->rows+i
>> end

I later added a 'continue' in here as Breakpoint 6 in the output.

>> end

> Also, let's see if scrolling_1 is ever called:

>   (gdb) break scrolling_1
>   (gdb) commands
>> continue
>> end
>   (gdb)

> The goal is to understand why Emacs is redrawing the display although
> nothing on display changes.  There's some convoluted code in
> update_frame_line, a subroutine of update_frame_1, which attempts to
> find the differences between the current line on display and what
> should be on the current line, and only redraw the part(s) that
> changed.  I'd expect that code to figure out that nothing needs to be
> redrawn in this case, but somehow it fails, I don't yet see why.

Not sure if the attached gdb output is any useful. Here is what I did:

- emacs -Q 
- M-x server-start
- gdb stuff, breakpoints + loading .gdbinit
- Started an xterm of dimensions (maybe 20-25 rows)
- emacsclient -t
- key presses (none of them is C-x C-f)
- Breakpoint 1 being hit and requiring me to type 'cont' on every hit
- After some 'cont' inputs, I deleted it, and re-added it as Breakpoint 6 with
 'continue' as mentioned above.
- Breakpoint 6 being continuously hit
- C-x 5 0 in emacsclient window
- appended '====EMACSCLIENT STOPPED====' to logfile
- emacsclient -t
- Breakpoint 6 being hit
- I resized window to 4-5 rows in an effort to reduce no. of redraw messages
- Killed gdb after 2 minutes, which killed emacs.

Let me know if you need more information.

Thanks
-- 
Ashish SHUKLA

“Tous pour un, un pour tous, c'est notre devise” (Alexandre Dumas, père, "Les
Trois Mousquetaires", 1844)

Sent from my Emacs

[-- Attachment #1.2: gdb.txt.xz --]
[-- Type: application/octet-stream, Size: 4024 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Eli Zaretskii]

> From: ashish.is@lostca.se (Ashish SHUKLA)
> Cc: 13864@debbugs.gnu.org
> Date: Fri, 08 Mar 2013 15:38:30 +0530
> 
> >   (gdb) break dispnew.c:4509
> >   (gdb) commands
> >> p i
> >> p desired_matrix->nrows
> >> if i < desired_matrix->nrows
> >> pgrowx desired_matrix->rows+i
> >> end
> 
> I later added a 'continue' in here as Breakpoint 6 in the output.

Yes, sorry about that, I forgot.

> Not sure if the attached gdb output is any useful.

It is, thanks.  I think we are making progress.

> - emacs -Q 
> - M-x server-start
> - gdb stuff, breakpoints + loading .gdbinit
> - Started an xterm of dimensions (maybe 20-25 rows)
> - emacsclient -t
> - key presses (none of them is C-x C-f)

Emacs would begin to flicker after these, right?

> - Breakpoint 1 being hit and requiring me to type 'cont' on every hit
> - After some 'cont' inputs, I deleted it, and re-added it as Breakpoint 6 with
>  'continue' as mentioned above.
> - Breakpoint 6 being continuously hit

So you are saying that scrolling_1 is never called, is that right?

> - C-x 5 0 in emacsclient window
> - appended '====EMACSCLIENT STOPPED====' to logfile
> - emacsclient -t
> - Breakpoint 6 being hit
> - I resized window to 4-5 rows in an effort to reduce no. of redraw messages
> - Killed gdb after 2 minutes, which killed emacs.

To have a way of terminating the session in a more civilized way, I
frequently use the following trick: put a breakpoint at Fredraw_display,
before you start the debugging session.  Then, whenever you want to
change something or finish the session, just "M-x redraw-display RET"
and GDB kicks in.

> Let me know if you need more information.

Hmm...  Some observations:

  . update_frame_1 is constantly called with either the entire frame,
    starting with the menu bar, or just with the last line of the
    frame, which is the echo area.

  . I see tooltip messages being displayed in the echo area.  You have
    a mouse active (as far as Emacs is concerned) on the xterm frame,
    is that right?  Can you disable it and see if the flickering
    persists?

  . There are some instances where Emacs displayed "Quit" in the echo
    area.  Did you type C-g or some such?

Moving on in the investigation of the problem (assuming that
disabling the mouse doesn't fix it), I assume that the function
update_frame_line is being called to redraw the xterm frame, given the
evidence you gathered this far.  First, let's make sure this is indeed
so.  Use this breakpoint:

  (gdb) break update_frame_line
  (gdb) commands
   > p vpos
   > continue
   > end
  (gdb)

Please see if you see all the line numbers when you recreate the
situation with flickering.

If you indeed see all the line numbers of a frame, next thing is to
find out whether on your system the FRAME_CHAR_INS_DEL_OK macro
returns zero or non-zero.  (Depending on that, Emacs uses two separate
portions of code in update_frame_line which try to avoid redrawing the
parts of screen that didn't change.)  You could, for example, put a
breakpoint inside this block:

  if (!FRAME_CHAR_INS_DEL_OK (f))
    {
      int i, j;

      /* Find the first glyph in desired row that doesn't agree with
	 a glyph in the current row, and write the rest from there on.  */
      for (i = 0; i < nlen; i++)
	{
	  if (i >= olen || !GLYPH_EQUAL_P (nbody + i, obody + i))
	    {
	      /* Find the end of the run of different glyphs.  */
	      j = i + 1;
	      while (j < nlen
		     && (j >= olen
			 || !GLYPH_EQUAL_P (nbody + j, obody + j)
			 || CHAR_GLYPH_PADDING_P (nbody[j])))
		++j;

	      /* Output this run of non-matching chars.  */
	      cursor_to (f, vpos, i);
	      write_glyphs (f, nbody + i, j - i);
	      i = j - 1;

	      /* Now find the next non-match.  */
	    }
	}

      /* Clear the rest of the line, or the non-clear part of it.  */
      if (olen > nlen)
	{
	  cursor_to (f, vpos, nlen);
	  clear_end_of_line (f, olen);
	}

      /* Make current row = desired row.  */
      make_current (desired_matrix, current_matrix, vpos);
      return;  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    }

on the marked line, and see if it ever breaks.

Thanks.

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Ashish SHUKLA]

[-- Attachment #1.1: Type: text/plain, Size: 5593 bytes --]

Hi Eli,

Sorry for the delay in follow-up.

On Fri, 08 Mar 2013 17:58:47 +0200, Eli Zaretskii <eliz@gnu.org> said:
>> From: ashish.is@lostca.se (Ashish SHUKLA)
>> Cc: 13864@debbugs.gnu.org
>> Date: Fri, 08 Mar 2013 15:38:30 +0530
>> 
>> >   (gdb) break dispnew.c:4509
>> >   (gdb) commands
>> >> p i
>> >> p desired_matrix->nrows
>> >> if i < desired_matrix->nrows
>> >> pgrowx desired_matrix->rows+i
>> >> end
>> 
>> I later added a 'continue' in here as Breakpoint 6 in the output.

> Yes, sorry about that, I forgot.

>> Not sure if the attached gdb output is any useful.

> It is, thanks.  I think we are making progress.

>> - emacs -Q 
>> - M-x server-start
>> - gdb stuff, breakpoints + loading .gdbinit
>> - Started an xterm of dimensions (maybe 20-25 rows)
>> - emacsclient -t
>> - key presses (none of them is C-x C-f)

> Emacs would begin to flicker after these, right?

No, it only starts flickering after I focus to X11 window and focus back to
emacsclient xterm window. Apologies, if I wasn't clear before in my
observations.

>> - Breakpoint 1 being hit and requiring me to type 'cont' on every hit
>> - After some 'cont' inputs, I deleted it, and re-added it as Breakpoint 6 with
>> 'continue' as mentioned above.
>> - Breakpoint 6 being continuously hit

> So you are saying that scrolling_1 is never called, is that right?

Right.

>> - C-x 5 0 in emacsclient window
>> - appended '====EMACSCLIENT STOPPED====' to logfile
>> - emacsclient -t
>> - Breakpoint 6 being hit
>> - I resized window to 4-5 rows in an effort to reduce no. of redraw messages
>> - Killed gdb after 2 minutes, which killed emacs.

> To have a way of terminating the session in a more civilized way, I
> frequently use the following trick: put a breakpoint at Fredraw_display,
> before you start the debugging session.  Then, whenever you want to
> change something or finish the session, just "M-x redraw-display RET"
> and GDB kicks in.

>> Let me know if you need more information.

> Hmm...  Some observations:

>   . update_frame_1 is constantly called with either the entire frame,
>     starting with the menu bar, or just with the last line of the
>     frame, which is the echo area.

>   . I see tooltip messages being displayed in the echo area.  You have
>     a mouse active (as far as Emacs is concerned) on the xterm frame,
>     is that right?  Can you disable it and see if the flickering
>     persists?

I don't know what you meant by mouse active. FTR, I don't use
"xterm-mouse-mode" in my .emacs.d/init.el nor the -Q config has that, if
that's what you're implying. Emacs instance in xterm doesn't have any effect
of mouse in it. The tooltip is courtesy some spurious key-presses during
debugging..

>   . There are some instances where Emacs displayed "Quit" in the echo
>     area.  Did you type C-g or some such?

Right, I did type that.

> Moving on in the investigation of the problem (assuming that
> disabling the mouse doesn't fix it), I assume that the function
> update_frame_line is being called to redraw the xterm frame, given the
> evidence you gathered this far.  First, let's make sure this is indeed
> so.  Use this breakpoint:

>   (gdb) break update_frame_line
>   (gdb) commands
>> p vpos
>> continue
>> end
>   (gdb)

> Please see if you see all the line numbers when you recreate the
> situation with flickering.

Yes, I saw them, the output is in "gdb-1.txt" attachment. The GDB output has
inline comments prefixed with '===='.

> If you indeed see all the line numbers of a frame, next thing is to
> find out whether on your system the FRAME_CHAR_INS_DEL_OK macro
> returns zero or non-zero.  (Depending on that, Emacs uses two separate
> portions of code in update_frame_line which try to avoid redrawing the
> parts of screen that didn't change.)  You could, for example, put a
> breakpoint inside this block:

>   if (!FRAME_CHAR_INS_DEL_OK (f))
>     {
>       int i, j;

>       /* Find the first glyph in desired row that doesn't agree with
> 	 a glyph in the current row, and write the rest from there on.  */
>       for (i = 0; i < nlen; i++)
> 	{
> 	  if (i >= olen || !GLYPH_EQUAL_P (nbody + i, obody + i))
> 	    {
> 	      /* Find the end of the run of different glyphs.  */
> 	      j = i + 1;
> 	      while (j < nlen
> 		     && (j >= olen
> 			 || !GLYPH_EQUAL_P (nbody + j, obody + j)
> 			 || CHAR_GLYPH_PADDING_P (nbody[j])))
> 		++j;

> 	      /* Output this run of non-matching chars.  */
> 	      cursor_to (f, vpos, i);
> 	      write_glyphs (f, nbody + i, j - i);
> 	      i = j - 1;

> 	      /* Now find the next non-match.  */
> 	    }
> 	}

>       /* Clear the rest of the line, or the non-clear part of it.  */
>       if (olen > nlen)
> 	{
> 	  cursor_to (f, vpos, nlen);
> 	  clear_end_of_line (f, olen);
> 	}

>       /* Make current row = desired row.  */
>       make_current (desired_matrix, current_matrix, vpos);
>       return;  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>     }

> on the marked line, and see if it ever breaks.

This output is in "gdb-2.txt" with inline comments.

The comments are added with: echo '==== $MESSAGE ====' >>gdb.txt
in a different xterm window.

FTR, I use Fluxbox 1.3.5 as my window manager, and running Xorg 7.5.2.

Let me know if you need anything else.

HTH
-- 
Ashish SHUKLA

“It is neccessary to have wished for death in order to know how good it is to
live.” ("Alexandre Dumas")

Sent from my Emacs

[-- Attachment #1.2: gdb-1.txt.xz --]
[-- Type: application/octet-stream, Size: 41560 bytes --]

[-- Attachment #1.3: gdb-2.txt.xz --]
[-- Type: application/octet-stream, Size: 3656 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Eli Zaretskii]

> From: ashish.is@lostca.se (Ashish SHUKLA)
> Cc: 13864@debbugs.gnu.org
> Date: Wed, 13 Mar 2013 14:30:05 +0530
> 
> Sorry for the delay in follow-up.

No need to apologize, we all have our lives.

> No, it only starts flickering after I focus to X11 window and focus back to
> emacsclient xterm window. Apologies, if I wasn't clear before in my
> observations.

Please make it flicker for collecting the data I describe below, it is
very important for me to be sure that the data is relevant.

> > So you are saying that scrolling_1 is never called, is that right?
> 
> Right.

OK, that makes the list of suspects quite a bit shorter.

> >   . I see tooltip messages being displayed in the echo area.  You have
> >     a mouse active (as far as Emacs is concerned) on the xterm frame,
> >     is that right?  Can you disable it and see if the flickering
> >     persists?
> 
> I don't know what you meant by mouse active. FTR, I don't use
> "xterm-mouse-mode" in my .emacs.d/init.el nor the -Q config has that, if
> that's what you're implying. Emacs instance in xterm doesn't have any effect
> of mouse in it. The tooltip is courtesy some spurious key-presses during
> debugging..

That's strange, I'm probably missing something.  Not terribly
important (it's tangential to the issue I'm hunting with your GDB
collected data), but could you give me a recipe to cause such a
tooltip in the xterm frame by some key-press?

> >   (gdb) break update_frame_line
> >   (gdb) commands
> >> p vpos
> >> continue
> >> end
> >   (gdb)
> 
> > Please see if you see all the line numbers when you recreate the
> > situation with flickering.
> 
> Yes, I saw them, the output is in "gdb-1.txt" attachment. The GDB output has
> inline comments prefixed with '===='.

OK, that means Emacs tries to redraw the entire frame, line by line.

> >   if (!FRAME_CHAR_INS_DEL_OK (f))
> >     {
> >       int i, j;
> 
> >       /* Find the first glyph in desired row that doesn't agree with
> > 	 a glyph in the current row, and write the rest from there on.  */
> >       for (i = 0; i < nlen; i++)
> > 	{
> > 	  if (i >= olen || !GLYPH_EQUAL_P (nbody + i, obody + i))
> > 	    {
> > 	      /* Find the end of the run of different glyphs.  */
> > 	      j = i + 1;
> > 	      while (j < nlen
> > 		     && (j >= olen
> > 			 || !GLYPH_EQUAL_P (nbody + j, obody + j)
> > 			 || CHAR_GLYPH_PADDING_P (nbody[j])))
> > 		++j;
> 
> > 	      /* Output this run of non-matching chars.  */
> > 	      cursor_to (f, vpos, i);
> > 	      write_glyphs (f, nbody + i, j - i);
> > 	      i = j - 1;
> 
> > 	      /* Now find the next non-match.  */
> > 	    }
> > 	}
> 
> >       /* Clear the rest of the line, or the non-clear part of it.  */
> >       if (olen > nlen)
> > 	{
> > 	  cursor_to (f, vpos, nlen);
> > 	  clear_end_of_line (f, olen);
> > 	}
> 
> >       /* Make current row = desired row.  */
> >       make_current (desired_matrix, current_matrix, vpos);
> >       return;  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> >     }
> 
> > on the marked line, and see if it ever breaks.
> 
> This output is in "gdb-2.txt" with inline comments.

I see that breakpoint never breaks, which would mean
FRAME_CHAR_INS_DEL_OK returns non-zero on your xterm, as expected.
Again, this trims the list of suspects.

So now the problem description is this:

 . update_frame_line is being called for every line of the frame.  I
   don't yet know why, nor whether this is a bug or not, but it's a
   separate issue anyway.

 . There's code in update_frame_line that attempts to avoid redrawing
   the portions of display that are already up to date, i.e. that are
   unchanged since the last redisplay cycle.  The flickering and your
   truss output indicate that significant portions of the display are
   being redrawn nonetheless.  The question is, why?  What code in
   update_frame_line fails to detect that most or all of the display
   did not change at all, and why?

To answer the last questions, please use the following GDB setup.
(Please verify the line numbers before you set each breakpoint, in
case your sources are slightly different from what I'm using to write
this message.)

 (gdb) break dispnew.c:4845
 (gdb) commands
  > p vpos
  > p desired_row->used[1]
  > p nlen
  > continue
  > end

This puts a breakpoint on this line:

      /* Write the contents of the desired line.  */
      if (nlen)
	{
          cursor_to (f, vpos, 0);
	  write_glyphs (f, nbody, nlen);  <<<<<<<<<<<<<<<<<<<<<<<
	}

 (gdb) break dispnew.c:4854
 (gdb) commands
  > p vpos
  > p f->total_cols  
  > p nlen
  > continue
  > end
 (gdb) break dispnew.c:4859
 (gdb) commands
  > p vpos
  > continue
  > end

These 2 breakpoints are here:

      if (nlen < FRAME_TOTAL_COLS (f))
	{
	  cursor_to (f, vpos, nlen);
          clear_end_of_line (f, FRAME_TOTAL_COLS (f));  <<<<<<<<<<<<<<<
	}
      else
	/* Make sure we are in the right row, otherwise cursor movement
	   with cmgoto might use `ch' in the wrong row.  */
	cursor_to (f, vpos, 0);  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

 (gdb) break dispnew.c:4926
 (gdb) commands
  > p vpos
  > p desired_row->used[1]
  > p nlen
  > p nsp
  > continue
  > end

This breakpoint is here:

      if (nlen > nsp)
	{
	  cursor_to (f, vpos, nsp);
	  write_glyphs (f, nbody + nsp, nlen - nsp);  <<<<<<<<<<<<<<<<<<
	}

 (gdb) break dispnew.c:4999
 (gdb) commands
  > p vpos
  > p olen
  > p osp
  > p desired_row->used[1]
  > p nsp
  > continue
  > end

This is here:

  /* Now go through the line, inserting, writing and
     deleting as appropriate.  */

  if (osp > nsp)
    {
      cursor_to (f, vpos, nsp);
      delete_glyphs (f, osp - nsp);  <<<<<<<<<<<<<<<<<<<<<<
    }

 (gdb) break dispnew.c:5006
 (gdb) commands
  > p vpos
  > p nsp
  > p osp
  > p begmatch
  > p endmatch
  > p olen
  > p nlen
  > continue
  > end

This breakpoint is here:

  else if (nsp > osp)
    {
      /* If going to delete chars later in line
	 and insert earlier in the line,
	 must delete first to avoid losing data in the insert */
      if (endmatch && nlen < olen + nsp - osp)  <<<<<<<<<<<<<<<<<<<<<<
	{
	  cursor_to (f, vpos, nlen - endmatch + osp - nsp);
	  delete_glyphs (f, olen + nsp - osp - nlen);
	  olen = nlen - (nsp - osp);
	}

 (gdb) break dispnew.c:5035
 (gdb) commands
  > p vpos
  > p nsp
  > p osp
  > p begmatch
  > p endmatch
  > p olen
  > p nlen
  > p desired_row->used[1]
  > p tem
  > continue
  > end

This puts a breakpoint here:

	  /* Function write_glyphs is prepared to do nothing
	     if passed a length <= 0.  Check it here to avoid
	     unnecessary cursor movement.  */
	  if (nlen - tem > 0)
	    {
	      cursor_to (f, vpos, nsp + begmatch);
	      write_glyphs (f, nbody + nsp + begmatch, nlen - tem); <<<<<<<
	    }

Two more breakpoints with similar commands:

 (gdb) break dispnew.c:5063
 (gdb) commands
  > p vpos
  > p nsp
  > p osp
  > p begmatch
  > p endmatch
  > p olen
  > p nlen
  > p desired_row->used[1]
  > p tem
  > p del
  > p out
  > continue
  > end
 (gdb) break dispnew.c:5069
 (gdb) commands
  > p vpos
  > p nsp
  > p osp
  > p begmatch
  > p endmatch
  > p olen
  > p nlen
  > p desired_row->used[1]
  > p tem
  > continue
  > end

They are here:


	  /* If we left columns to be overwritten, we must delete them.  */
	  del = olen - tem - out;
	  if (del > 0)
	    delete_glyphs (f, del);

	  /* At last, we insert columns not yet written out.  */
	  insert_glyphs (f, nbody + nsp + begmatch + out, nlen - olen + del); <<<<<<<<<<<
	  olen = nlen;
	}
      else if (olen > nlen)
	{
	  cursor_to (f, vpos, nsp + begmatch);
	  write_glyphs (f, nbody + nsp + begmatch, nlen - tem); <<<<<<<<<<<
	  delete_glyphs (f, olen - nlen);
	  olen = nlen;
	}

And the last one:

 (gdb) break dispnew.c:5080
 (gdb) commands
  > p vpos
  > p olen
  > p nlen
  > p desired_row->used[1]
  > p desired_row->enabled_p
  > continue
  > end

This breakpoint is here:

 just_erase:
  /* If any unerased characters remain after the new line, erase them.  */
  if (olen > nlen)
    {
      cursor_to (f, vpos, nlen);
      clear_end_of_line (f, olen); <<<<<<<<<<<<<<<<<<<
    }

This is certainly a lot of typing, so I suggest to put it all (sans
the "(gdb)" and ">" parts) in a file, and then "source that-file" from
inside GDB.  This way, you will be able to repeat the experiment
without going through the pain of retyping it all again.  (Don't
forget adding to that file "set logging on" and a breakpoint on
Fredraw_display.)

Once you are set up in GDB, make Emacs flicker, and collect the data
printed by GDB.  The goal of these breakpoints is to see which code is
involved in the flickering situation, and which parts of it are
actually writing to the screen.

Thanks.

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Ashish SHUKLA]

[-- Attachment #1.1: Type: text/plain, Size: 3437 bytes --]

On Fri, 15 Mar 2013 11:39:34 +0200, Eli Zaretskii <eliz@gnu.org> said:
>> From: ashish.is@lostca.se (Ashish SHUKLA)
>> Cc: 13864@debbugs.gnu.org
>> Date: Wed, 13 Mar 2013 14:30:05 +0530

[...]

>> I don't know what you meant by mouse active. FTR, I don't use
>> "xterm-mouse-mode" in my .emacs.d/init.el nor the -Q config has that, if
>> that's what you're implying. Emacs instance in xterm doesn't have any effect
>> of mouse in it. The tooltip is courtesy some spurious key-presses during
>> debugging..

> That's strange, I'm probably missing something.  Not terribly
> important (it's tangential to the issue I'm hunting with your GDB
> collected data), but could you give me a recipe to cause such a
> tooltip in the xterm frame by some key-press?

Sure, you set a breakpoint to some function which gets invoked as 'emacsclient
-t' starts, like update_frame_line, but forgot to add 'cont' to the list of
commands. And then you forgot that you didn't add 'cont' and starts
'emacsclient -t' and start typing (like some arrow key) without noticing that
'emacsclient' frame has yet to appear on the screen. Now look at gdb window,
breakpoint must have it, do 'cont' there so that emacsclient starts, and now
you'll see some characters in buffer, with "End of buffer" message in
minibuffer (tooltip).

[...]

> To answer the last questions, please use the following GDB setup.
> (Please verify the line numbers before you set each breakpoint, in
> case your sources are slightly different from what I'm using to write
> this message.)

FTR, I'm still running r111924 for this debugging to avoid adding more
variables.

[...]

> This is certainly a lot of typing, so I suggest to put it all (sans
> the "(gdb)" and ">" parts) in a file, and then "source that-file" from
> inside GDB.  This way, you will be able to repeat the experiment
> without going through the pain of retyping it all again.  (Don't
> forget adding to that file "set logging on" and a breakpoint on
> Fredraw_display.)

Done.

> Once you are set up in GDB, make Emacs flicker, and collect the data
> printed by GDB.  The goal of these breakpoints is to see which code is
> involved in the flickering situation, and which parts of it are
> actually writing to the screen.

The output is attached though I forgot to prefix my inline annotations during
gdb. Here are they from the my shell history:

#v+
  184  echo Starting emacsclient -t >>gdb.txt
  185  echo 'Typing "foobar" in emacsclient window' >>gdb.txt
  186  echo 'Now hovering mouse over X11 window' >>gdb.txt
  187  echo 'Now focusing to emacsclient xterm by clicking on xterm titlebar' >>gdb.txt
  188  echo 'Now typing "foobar" in emacsclient xterm' >>gdb.txt
  189  echo 'Typed "foobar" two more times in emacsclient xterm ^^^, and no flicker yet' >>gdb.txt
  190  echo 'Switching to X11 window' >>gdb.txt
  191  echo 'Switching back to xterm window and typing "foobar"' >>gdb.txt
  192  echo 'I only typed "foo" and it started flickering ^^^^^ vvvvv' >>gdb.txt
  193  echo 'Typing C-g and M-x redraw-display' >>gdb.txt
  194  echo 'Flickering stopped after C-g, now M-x redraw-display ' >>gdb.txt
  195  echo 'While typing: M-x redraw-display it started flickering again' >>gdb.txt
#v-

HTH
-- 
Ashish SHUKLA

“Does history record any case in which the majority was right?” (Robert
A. Heinlein, 1973)

Sent from my Emacs

[-- Attachment #1.2: GDB output --]
[-- Type: application/octet-stream, Size: 131904 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Eli Zaretskii]

> From: ashish.is@lostca.se (Ashish SHUKLA)
> Cc: 13864@debbugs.gnu.org
> Date: Fri, 22 Mar 2013 18:14:22 +0530
> 
> > That's strange, I'm probably missing something.  Not terribly
> > important (it's tangential to the issue I'm hunting with your GDB
> > collected data), but could you give me a recipe to cause such a
> > tooltip in the xterm frame by some key-press?
> 
> Sure, you set a breakpoint to some function which gets invoked as 'emacsclient
> -t' starts, like update_frame_line, but forgot to add 'cont' to the list of
> commands. And then you forgot that you didn't add 'cont' and starts
> 'emacsclient -t' and start typing (like some arrow key) without noticing that
> 'emacsclient' frame has yet to appear on the screen. Now look at gdb window,
> breakpoint must have it, do 'cont' there so that emacsclient starts, and now
> you'll see some characters in buffer, with "End of buffer" message in
> minibuffer (tooltip).

But the text I saw was different: it was the text of a tooltip for
mouse-sensitive portions of the mode line:

 Major mode, mouse-1: Display major mode menu, mouse-2: Show help for major mode

Strange.  Anyway, you can forget this for now; if this is important,
we'll get back to it later.

> FTR, I'm still running r111924 for this debugging to avoid adding more
> variables.

OK, that's good.

> > Once you are set up in GDB, make Emacs flicker, and collect the data
> > printed by GDB.  The goal of these breakpoints is to see which code is
> > involved in the flickering situation, and which parts of it are
> > actually writing to the screen.
> 
> The output is attached

Thanks.  Here's what flickering looks like:

  Breakpoint 4, update_frame_line (f=0x12efd88, vpos=0) at dispnew.c:4845
  4845		  write_glyphs (f, nbody, nlen);
  $36808 = 0
  $36809 = 239
  $36810 = 239

  Breakpoint 6, update_frame_line (f=0x12efd88, vpos=0) at dispnew.c:4859
  4859		cursor_to (f, vpos, 0);
  $36811 = 0

  Breakpoint 4, update_frame_line (f=0x12efd88, vpos=1) at dispnew.c:4845
  4845		  write_glyphs (f, nbody, nlen);
  $36812 = 1
  $36813 = 239
  $36814 = 239

  Breakpoint 6, update_frame_line (f=0x12efd88, vpos=1) at dispnew.c:4859
  4859		cursor_to (f, vpos, 0);
  $36815 = 1

  Breakpoint 4, update_frame_line (f=0x12efd88, vpos=2) at dispnew.c:4845
  4845		  write_glyphs (f, nbody, nlen);
  $36816 = 2
  $36817 = 239
  $36818 = 239

  Breakpoint 6, update_frame_line (f=0x12efd88, vpos=2) at dispnew.c:4859
  4859		cursor_to (f, vpos, 0);
  $36819 = 2

  Breakpoint 4, update_frame_line (f=0x12efd88, vpos=3) at dispnew.c:4845
  4845		  write_glyphs (f, nbody, nlen);
  $36820 = 3
  $36821 = 239
  $36822 = 239

  Breakpoint 6, update_frame_line (f=0x12efd88, vpos=3) at dispnew.c:4859
  4859		cursor_to (f, vpos, 0);
  $36823 = 3

  Breakpoint 5, update_frame_line (f=0x12efd88, vpos=4) at dispnew.c:4854
  4854	          clear_end_of_line (f, FRAME_TOTAL_COLS (f));
  $36824 = 4
  $36825 = 239
  $36826 = 0

  Breakpoint 4, update_frame_line (f=0x12efd88, vpos=5) at dispnew.c:4845
  4845		  write_glyphs (f, nbody, nlen);
  $36827 = 5
  $36828 = 239
  $36829 = 27

  Breakpoint 5, update_frame_line (f=0x12efd88, vpos=5) at dispnew.c:4854
  4854	          clear_end_of_line (f, FRAME_TOTAL_COLS (f));
  $36830 = 5
  $36831 = 239
  $36832 = 27

  Breakpoint 5, update_frame_line (f=0x12efd88, vpos=6) at dispnew.c:4854
  4854	          clear_end_of_line (f, FRAME_TOTAL_COLS (f));
  $36833 = 6
  $36834 = 239
  $36835 = 0

  Breakpoint 5, update_frame_line (f=0x12efd88, vpos=7) at dispnew.c:4854
  4854	          clear_end_of_line (f, FRAME_TOTAL_COLS (f));
  $36836 = 7
  $36837 = 239
  $36838 = 0

  Breakpoint 5, update_frame_line (f=0x12efd88, vpos=8) at dispnew.c:4854
  4854	          clear_end_of_line (f, FRAME_TOTAL_COLS (f));
  $36839 = 8
  $36840 = 239
  $36841 = 0

etc., for all the lines of the TTY frame (note the vpos values going
from 0 to 43, for 43-line frame).  For each line on that frame, Emacs
first writes the characters, if any, of the text on that line, and
then clears to the end of the line.

This code is here:


  /* If display line has unknown contents, write the whole line.  */
  if (must_write_whole_line_p)
    {
      [...]
      /* Write the contents of the desired line.  */
      if (nlen)
	{
          cursor_to (f, vpos, 0);
	  write_glyphs (f, nbody, nlen);
	}

      /* Don't call clear_end_of_line if we already wrote the whole
	 line.  The cursor will not be at the right margin in that
	 case but in the line below.  */
      if (nlen < FRAME_TOTAL_COLS (f))
	{
	  cursor_to (f, vpos, nlen);
          clear_end_of_line (f, FRAME_TOTAL_COLS (f));
	}
      else

and must_write_whole_line_p is computed like this:

  /* Current row not enabled means it has unknown contents.  We must
     write the whole desired line in that case.  */
  must_write_whole_line_p = !current_row->enabled_p;

IOW, the problem that causes continuous redrawing of the entire frame
is that every single line ("glyph row") of that frame is marked as
"not enabled" (i.e., invalid) in the current glyph matrix, which is a
structure that describes what is currently on the glass.

The current matrix has every one of its lines marked as valid at the
end of each redisplay cycle.  So the question now is: which code
resets those enabled_p flags of every glyph row in the current matrix,
and thus defeats the code that avoids redrawing the same contents?

To answer that, let's put a watchpoint at the enabled_p flag of one of
the glyph rows.  Like this:

 (gdb) break dispnew.c:2623 if vpos == 5

This breakpoint is inside the make_current function:

  static void
  make_current (struct glyph_matrix *desired_matrix, struct glyph_matrix *current_matrix, int row)
  {
    struct glyph_row *current_row = MATRIX_ROW (current_matrix, row);
    struct glyph_row *desired_row = MATRIX_ROW (desired_matrix, row);
    bool mouse_face_p = current_row->mouse_face_p;

    /* Do current_row = desired_row.  This exchanges glyph pointers
       between both rows, and does a structure assignment otherwise.  */
    assign_row (current_row, desired_row);

    /* Enable current_row to mark it as valid.  */
    current_row->enabled_p = 1;
    current_row->mouse_face_p = mouse_face_p;  <<<<<<<<<<<<<<<<<<<<<<

The choice of the line (5) is arbitrary.  Then wait until the
breakpoint breaks, and do this:

 (gdb) p current_row
 $1 = (struct glyph_row *) 0x37e1158

(The address will be different in your case.)  Now use that address to
put a hardware watchpoint on the enabled_p flag of that glyph row, and
continue the program:

 (gdb) watch ((struct glyph_row *) 0x37e1158)->enabled_p
 (gdb) c

Now do whatever it takes to cause the flicker, and wait for the
watchpoint to trigger, it should say something like

 Hardware watchpoint 5: ((struct glyph_row *) 0x37e1158)->enabled_p

 Old value = 1
 New value = 0

and will next show the source line which modified the value.  Then
type

 (gdb) bt

and let it continue

 (gdb) c

Do this several times, each time waiting until the watchpoint
triggers, and displaying the backtrace.  That should point towards the
code which resets these flags and causes excessive re-drawing.

Thanks.

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Ashish SHUKLA]

[-- Attachment #1.1: Type: text/plain, Size: 2264 bytes --]

On Sun, 24 Mar 2013 21:54:04 +0200, Eli Zaretskii <eliz@gnu.org> said:

[...]


>  (gdb) break dispnew.c:2623 if vpos == 5

s/vpos/row/ I guess, which is what attached gdb output is with.

> This breakpoint is inside the make_current function:

>   static void
>   make_current (struct glyph_matrix *desired_matrix, struct glyph_matrix *current_matrix, int row)
>   {
>     struct glyph_row *current_row = MATRIX_ROW (current_matrix, row);
>     struct glyph_row *desired_row = MATRIX_ROW (desired_matrix, row);
>     bool mouse_face_p = current_row->mouse_face_p;

>     /* Do current_row = desired_row.  This exchanges glyph pointers
>        between both rows, and does a structure assignment otherwise.  */
>     assign_row (current_row, desired_row);

>     /* Enable current_row to mark it as valid.  */
current_row-> enabled_p = 1;
current_row-> mouse_face_p = mouse_face_p;  <<<<<<<<<<<<<<<<<<<<<<

> The choice of the line (5) is arbitrary.  Then wait until the
> breakpoint breaks, and do this:

>  (gdb) p current_row
>  $1 = (struct glyph_row *) 0x37e1158

> (The address will be different in your case.)  Now use that address to
> put a hardware watchpoint on the enabled_p flag of that glyph row, and
> continue the program:

>  (gdb) watch ((struct glyph_row *) 0x37e1158)->enabled_p
>  (gdb) c

> Now do whatever it takes to cause the flicker, and wait for the
> watchpoint to trigger, it should say something like

>  Hardware watchpoint 5: ((struct glyph_row *) 0x37e1158)->enabled_p

>  Old value = 1
>  New value = 0

> and will next show the source line which modified the value.  Then
> type

>  (gdb) bt

> and let it continue

>  (gdb) c

> Do this several times, each time waiting until the watchpoint
> triggers, and displaying the backtrace.  That should point towards the
> code which resets these flags and causes excessive re-drawing.

Please refer to the attached gdb output with annotations prefixed with '=====> '.

Thanks
-- 
Ashish SHUKLA

“It's good to be wrong. Don't feel shamed. Wear past mistakes as a badge of
honor because growth is everything. To stop learning is to decay.”
("apokalyptik", "in a conversation to abbe", 2010)

Sent from my Emacs

[-- Attachment #1.2: gdb.txt.xz --]
[-- Type: application/octet-stream, Size: 5140 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Eli Zaretskii]

> From: ashish.is@lostca.se (Ashish SHUKLA)
> Cc: 13864@debbugs.gnu.org
> Date: Mon, 25 Mar 2013 14:58:08 +0530
> 
> >  (gdb) break dispnew.c:2623 if vpos == 5
> 
> s/vpos/row/ I guess

Yes, sorry.

> Please refer to the attached gdb output with annotations prefixed with '=====> '.

OK, the reason for constant redrawing of the emacsclient TTY frame is
that Emacs thinks that frame is "garbaged" (i.e. its display is
completely outdated and should be redrawn):

  Hardware watchpoint 6: ((struct glyph_row *) 0x196e500)->enabled_p

  Old value = 1
  New value = 0
  clear_glyph_matrix_rows (matrix=0x1825f00, start=5, end=28) at dispnew.c:728
  728	  for (; start < end; ++start)
  #0  clear_glyph_matrix_rows (matrix=0x1825f00, start=5, end=28) at dispnew.c:728
  #1  0x0000000000417028 in clear_glyph_matrix (matrix=0x1825f00) at dispnew.c:747
  #2  0x00000000004175bc in clear_current_matrices (f=0x117ac48) at dispnew.c:795
  #3  0x000000000044c348 in clear_garbaged_frames () at xdisp.c:10611
  #4  0x0000000000450de9 in redisplay_internal () at xdisp.c:12925

The function clear_garbaged_frames does this:

      FOR_EACH_FRAME (tail, frame)
	{
	  struct frame *f = XFRAME (frame);

	  if (FRAME_VISIBLE_P (f) && FRAME_GARBAGED_P (f)) <<<<<<<<<
	    {
	      if (f->resized_p)
		{
		  redraw_frame (f);
		  f->force_flush_display_p = 1;
		}
	      clear_current_matrices (f); <<<<<<<<<<<<<<<<<<<<<<<<<<<
	      changed_count++;
	      f->garbaged = 0;
	      f->resized_p = 0;
	    }
	}

And the call to clear_current_matrices invalidates the record of
what's currently displayed on the TTY frame, and therefore causes
constant redrawing of that frame.

So the question now is: which code sets the frame's 'garbaged' flag?
To find out, do this in GDB:

 (gdb) tbreak dispnew.c:4861 if vpos == 5
 (gdb) c

The breakpoint is here:

      else
	/* Make sure we are in the right row, otherwise cursor movement
	   with cmgoto might use `ch' in the wrong row.  */
	cursor_to (f, vpos, 0);

      make_current (desired_matrix, current_matrix, vpos); <<<<<<<<<<<<<<<<
      return;
    }

Note that the breakpoint is temporary ("tbreak"), so it will only
break once.  This is to avoid hitting it again, after you set the
watchpoint below, because we only need this breakpoint to find out the
address of the TTY frame structure, whose 'garbaged' flag we want to
watch.

When this breakpoint breaks, type these commands:

 (gdb) p f
 $1 = (struct frame *) 0x12345678
 (gdb) watch ((struct frame *) 0x12345678)->garbaged
 (gdb) commands
  > if ((struct frame *) 0x12345678)->garbaged == 1
  >   bt
  > end
  > continue
 (gdb)

Again, the value of f will be different in your case; use whatever GDB
shows in your case for the following 'watch' command.

Now do whatever is needed to cause Emacs flicker, and the backtrace
from the watchpoint should show who sets the garbaged flag of the TTY
frame.

Thanks.

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Ashish SHUKLA]

[-- Attachment #1.1: Type: text/plain, Size: 3605 bytes --]

On Mon, 25 Mar 2013 12:56:06 +0200, Eli Zaretskii <eliz@gnu.org> said:
>> From: ashish.is@lostca.se (Ashish SHUKLA)
>> Cc: 13864@debbugs.gnu.org
>> Date: Mon, 25 Mar 2013 14:58:08 +0530
>> 
>> >  (gdb) break dispnew.c:2623 if vpos == 5
>> 
>> s/vpos/row/ I guess

> Yes, sorry.

>> Please refer to the attached gdb output with annotations prefixed with '=====> '.

> OK, the reason for constant redrawing of the emacsclient TTY frame is
> that Emacs thinks that frame is "garbaged" (i.e. its display is
> completely outdated and should be redrawn):

>   Hardware watchpoint 6: ((struct glyph_row *) 0x196e500)->enabled_p

>   Old value = 1
>   New value = 0
>   clear_glyph_matrix_rows (matrix=0x1825f00, start=5, end=28) at dispnew.c:728
>   728	  for (; start < end; ++start)
>   #0  clear_glyph_matrix_rows (matrix=0x1825f00, start=5, end=28) at dispnew.c:728
>   #1  0x0000000000417028 in clear_glyph_matrix (matrix=0x1825f00) at dispnew.c:747
>   #2  0x00000000004175bc in clear_current_matrices (f=0x117ac48) at dispnew.c:795
>   #3  0x000000000044c348 in clear_garbaged_frames () at xdisp.c:10611
>   #4  0x0000000000450de9 in redisplay_internal () at xdisp.c:12925

> The function clear_garbaged_frames does this:

>       FOR_EACH_FRAME (tail, frame)
> 	{
> 	  struct frame *f = XFRAME (frame);

> 	  if (FRAME_VISIBLE_P (f) && FRAME_GARBAGED_P (f)) <<<<<<<<<
> 	    {
> 	      if (f->resized_p)
> 		{
> 		  redraw_frame (f);
f-> force_flush_display_p = 1;
> 		}
> 	      clear_current_matrices (f); <<<<<<<<<<<<<<<<<<<<<<<<<<<
> 	      changed_count++;
f-> garbaged = 0;
f-> resized_p = 0;
> 	    }
> 	}

> And the call to clear_current_matrices invalidates the record of
> what's currently displayed on the TTY frame, and therefore causes
> constant redrawing of that frame.

> So the question now is: which code sets the frame's 'garbaged' flag?
> To find out, do this in GDB:

>  (gdb) tbreak dispnew.c:4861 if vpos == 5
>  (gdb) c

> The breakpoint is here:

>       else
> 	/* Make sure we are in the right row, otherwise cursor movement
> 	   with cmgoto might use `ch' in the wrong row.  */
> 	cursor_to (f, vpos, 0);

>       make_current (desired_matrix, current_matrix, vpos); <<<<<<<<<<<<<<<<
>       return;
>     }

> Note that the breakpoint is temporary ("tbreak"), so it will only
> break once.  This is to avoid hitting it again, after you set the
> watchpoint below, because we only need this breakpoint to find out the
> address of the TTY frame structure, whose 'garbaged' flag we want to
> watch.

> When this breakpoint breaks, type these commands:

>  (gdb) p f
>  $1 = (struct frame *) 0x12345678
>  (gdb) watch ((struct frame *) 0x12345678)->garbaged
>  (gdb) commands
>> if ((struct frame *) 0x12345678)->garbaged == 1
>> bt
>> end
>> continue
>  (gdb)

> Again, the value of f will be different in your case; use whatever GDB
> shows in your case for the following 'watch' command.

> Now do whatever is needed to cause Emacs flicker, and the backtrace
> from the watchpoint should show who sets the garbaged flag of the TTY
> frame.

Please refer to the attached output. I'm not sure if it's for the right frame
(i.e. "garbaged" flag monitored for X11 frame, or emacsclient frame).

Let me know if you like me to take it again.

Thanks
-- 
Ashish SHUKLA

“Many of the convicted thieves Parker has met began their life of crime after
taking college Computer Science courses.” (Roger Rapoport, "Programs for
Plunder", Omni, March 1981)

Sent from my Emacs

[-- Attachment #1.2: gdb.txt.xz --]
[-- Type: application/octet-stream, Size: 4312 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Eli Zaretskii]

> From: ashish.is@lostca.se (Ashish SHUKLA)
> Cc: 13864@debbugs.gnu.org
> Date: Mon, 01 Apr 2013 22:15:46 +0530
> 
> Please refer to the attached output.

Thanks, I think we've finally nailed this sucker.

> I'm not sure if it's for the right frame (i.e. "garbaged" flag
> monitored for X11 frame, or emacsclient frame).

It is certainly for the right frame, because the code that sets the
"garbaged" flag is here:

  if (FRAME_TERMCAP_P (XFRAME (frame)) || FRAME_MSDOS_P (XFRAME (frame)))
    {
      if (FRAMEP (FRAME_TTY (XFRAME (frame))->top_frame))
	/* Mark previously displayed frame as now obscured.  */
	SET_FRAME_VISIBLE (XFRAME (FRAME_TTY (XFRAME (frame))->top_frame), 2);
      SET_FRAME_VISIBLE (XFRAME (frame), 1);  <<<<<<<<<<<<<<<<<<<<<<<<<<<
      FRAME_TTY (XFRAME (frame))->top_frame = frame;
    }

As you can see from the condition for this block, it is only run for
TTY (a.k.a. "termcap") frames.

I think the problem here is that the code sets the "garbaged" flag
even if the "top frame" of the TTY did not change at all.

Can you try the patch below?  Please try it both with a single TTY
frame on the xterm (in addition to a GUI frame), like what you did
until now, and also with several TTY frames on the same xterm (you can
create additional frames by "C-x 5" commands).

If this gives good results, I will install it.  Thanks.


=== modified file 'src/frame.c'
--- src/frame.c	2013-04-02 01:54:56 +0000
+++ src/frame.c	2013-04-02 17:06:50 +0000
@@ -803,10 +803,18 @@ do_switch_frame (Lisp_Object frame, int 
 
   if (FRAME_TERMCAP_P (XFRAME (frame)) || FRAME_MSDOS_P (XFRAME (frame)))
     {
-      if (FRAMEP (FRAME_TTY (XFRAME (frame))->top_frame))
-	/* Mark previously displayed frame as now obscured.  */
-	SET_FRAME_VISIBLE (XFRAME (FRAME_TTY (XFRAME (frame))->top_frame), 2);
-      SET_FRAME_VISIBLE (XFRAME (frame), 1);
+      Lisp_Object top_frame = FRAME_TTY (XFRAME (frame))->top_frame;
+
+      /* Don't mark the frame garbaged and/or obscured if we are
+	 switching to the frame that is already the top frame of that
+	 TTY.  */
+      if (!EQ (frame, top_frame))
+	{
+	  if (FRAMEP (top_frame))
+	    /* Mark previously displayed frame as now obscured.  */
+	    SET_FRAME_VISIBLE (XFRAME (top_frame), 2);
+	  SET_FRAME_VISIBLE (XFRAME (frame), 1);
+	}
       FRAME_TTY (XFRAME (frame))->top_frame = frame;
     }
 

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Ashish SHUKLA]

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

Hi Eli,

First of all sorry for the delay in reply.

On Tue, 02 Apr 2013 20:10:16 +0300, Eli Zaretskii <eliz@gnu.org> said:
>> From: ashish.is@lostca.se (Ashish SHUKLA)
>> Cc: 13864@debbugs.gnu.org
>> Date: Mon, 01 Apr 2013 22:15:46 +0530
>> 
>> Please refer to the attached output.

> Thanks, I think we've finally nailed this sucker.

Seems like you nailed indeed :-)

>> I'm not sure if it's for the right frame (i.e. "garbaged" flag
>> monitored for X11 frame, or emacsclient frame).

> It is certainly for the right frame, because the code that sets the
> "garbaged" flag is here:

>   if (FRAME_TERMCAP_P (XFRAME (frame)) || FRAME_MSDOS_P (XFRAME (frame)))
>     {
>       if (FRAMEP (FRAME_TTY (XFRAME (frame))->top_frame))
> 	/* Mark previously displayed frame as now obscured.  */
> 	SET_FRAME_VISIBLE (XFRAME (FRAME_TTY (XFRAME (frame))->top_frame), 2);
>       SET_FRAME_VISIBLE (XFRAME (frame), 1);  <<<<<<<<<<<<<<<<<<<<<<<<<<<
>       FRAME_TTY (XFRAME (frame))->top_frame = frame;
>     }

> As you can see from the condition for this block, it is only run for
> TTY (a.k.a. "termcap") frames.

> I think the problem here is that the code sets the "garbaged" flag
> even if the "top frame" of the TTY did not change at all.

> Can you try the patch below?  Please try it both with a single TTY
> frame on the xterm (in addition to a GUI frame), like what you did
> until now, and also with several TTY frames on the same xterm (you can
> create additional frames by "C-x 5" commands).

> If this gives good results, I will install it.  Thanks.

I've applied the diff over r112178 (which is what I'd checked out), and I
don't experience this issue any more with Emacs (with all the combinations
you've mentioned above).

Thanks!
-- 
Ashish SHUKLA

“Beware of altruism. It is based on self-deception, the root of all evil.”
(Robert A. Heinlein, 1973)

Sent from my Emacs

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11

[Eli Zaretskii]

> From: ashish.is@lostca.se (Ashish SHUKLA)
> Cc: 13864@debbugs.gnu.org
> Date: Wed, 10 Apr 2013 14:36:40 +0530
> 
> First of all sorry for the delay in reply.

No sweat.  The patch was safely stashed on a shelve.

> I've applied the diff over r112178 (which is what I'd checked out), and I
> don't experience this issue any more with Emacs (with all the combinations
> you've mentioned above).

Thanks.  I committed the changes as trunk revision 112264.  I'm
closing this bug; feel free to reopen if you find any left-overs.

Thanks again for all your invaluable help in solving this bug.