Package: emacs;
Reported by: Ashish SHUKLA <ashish.is <at> lostca.se>
Date: Mon, 4 Mar 2013 00:15:01 UTC
Severity: normal
Found in version 24.3.50
Done: Glenn Morris <rgm <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13864 in the body.
You can then email your comments to 13864 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Mon, 04 Mar 2013 00:15:01 GMT) Full text and rfc822 format available.Ashish SHUKLA <ashish.is <at> lostca.se>
:bug-gnu-emacs <at> gnu.org
.
(Mon, 04 Mar 2013 00:15:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Ashish SHUKLA <ashish.is <at> lostca.se> To: bug-gnu-emacs <at> gnu.org Subject: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Mon, 04 Mar 2013 00:49:47 +0530
[Message part 1 (text/plain, inline)]
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
[Message part 2 (application/pgp-signature, inline)]
bug-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Mon, 04 Mar 2013 17:52:01 GMT) Full text and rfc822 format available.Message #8 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Ashish SHUKLA <ashish.is <at> lostca.se> Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Mon, 04 Mar 2013 19:50:10 +0200
> From: Ashish SHUKLA <ashish.is <at> 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-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Mon, 04 Mar 2013 19:15:01 GMT) Full text and rfc822 format available.Message #11 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: ashish.is <at> lostca.se (Ashish SHUKLA) To: Eli Zaretskii <eliz <at> gnu.org> Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Tue, 05 Mar 2013 00:43:11 +0530
[Message part 1 (text/plain, inline)]
On Mon, 04 Mar 2013 19:50:10 +0200, Eli Zaretskii <eliz <at> gnu.org> said: >> From: Ashish SHUKLA <ashish.is <at> 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
[Message part 2 (application/pgp-signature, inline)]
bug-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Mon, 04 Mar 2013 20:23:02 GMT) Full text and rfc822 format available.Message #14 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: ashish.is <at> lostca.se (Ashish SHUKLA) Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Mon, 04 Mar 2013 22:22:30 +0200
> From: ashish.is <at> lostca.se (Ashish SHUKLA) > Cc: 13864 <at> 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-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Tue, 05 Mar 2013 00:28:02 GMT) Full text and rfc822 format available.Message #17 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: ashish.is <at> lostca.se (Ashish SHUKLA) To: Eli Zaretskii <eliz <at> gnu.org> Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Tue, 05 Mar 2013 05:56:40 +0530
[Message part 1 (text/plain, inline)]
On Mon, 04 Mar 2013 22:22:30 +0200, Eli Zaretskii <eliz <at> gnu.org> said: >> From: ashish.is <at> lostca.se (Ashish SHUKLA) >> Cc: 13864 <at> 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
[Message part 2 (application/pgp-signature, inline)]
bug-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Wed, 06 Mar 2013 17:09:01 GMT) Full text and rfc822 format available.Message #20 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: ashish.is <at> lostca.se (Ashish SHUKLA) Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Wed, 06 Mar 2013 19:07:36 +0200
> From: ashish.is <at> lostca.se (Ashish SHUKLA) > Cc: 13864 <at> 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-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Wed, 06 Mar 2013 18:54:01 GMT) Full text and rfc822 format available.Message #23 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: ashish.is <at> lostca.se (Ashish SHUKLA) To: Eli Zaretskii <eliz <at> gnu.org> Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Thu, 07 Mar 2013 00:22:43 +0530
[Message part 1 (text/plain, inline)]
On Wed, 06 Mar 2013 19:07:36 +0200, Eli Zaretskii <eliz <at> gnu.org> said: >> From: ashish.is <at> lostca.se (Ashish SHUKLA) >> Cc: 13864 <at> 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
[Message part 2 (application/pgp-signature, inline)]
bug-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Wed, 06 Mar 2013 21:02:02 GMT) Full text and rfc822 format available.Message #26 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: ashish.is <at> lostca.se (Ashish SHUKLA) Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Wed, 06 Mar 2013 23:00:18 +0200
> From: ashish.is <at> lostca.se (Ashish SHUKLA) > Cc: 13864 <at> 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-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Thu, 07 Mar 2013 01:45:01 GMT) Full text and rfc822 format available.Message #29 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: ashish.is <at> lostca.se (Ashish SHUKLA) To: Eli Zaretskii <eliz <at> gnu.org> Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Thu, 07 Mar 2013 07:13:46 +0530
[Message part 1 (text/plain, inline)]
On Wed, 06 Mar 2013 23:00:18 +0200, Eli Zaretskii <eliz <at> gnu.org> said: >> From: ashish.is <at> lostca.se (Ashish SHUKLA) >> Cc: 13864 <at> 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
[emacs-output.txt.xz (application/octet-stream, attachment)]
[Message part 3 (application/pgp-signature, inline)]
bug-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Thu, 07 Mar 2013 06:57:01 GMT) Full text and rfc822 format available.Message #32 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: ashish.is <at> lostca.se (Ashish SHUKLA) Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Thu, 07 Mar 2013 08:55:51 +0200
> From: ashish.is <at> lostca.se (Ashish SHUKLA) > Cc: 13864 <at> 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-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Thu, 07 Mar 2013 07:41:02 GMT) Full text and rfc822 format available.Message #35 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: ashish.is <at> lostca.se (Ashish SHUKLA) To: Eli Zaretskii <eliz <at> gnu.org> Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Thu, 07 Mar 2013 13:08:49 +0530
[Message part 1 (text/plain, inline)]
On Thu, 07 Mar 2013 08:55:51 +0200, Eli Zaretskii <eliz <at> gnu.org> said: >> From: ashish.is <at> lostca.se (Ashish SHUKLA) >> Cc: 13864 <at> 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
[Message part 2 (application/pgp-signature, inline)]
bug-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Thu, 07 Mar 2013 09:17:01 GMT) Full text and rfc822 format available.Message #38 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: ashish.is <at> lostca.se (Ashish SHUKLA) Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Thu, 07 Mar 2013 11:16:18 +0200
> From: ashish.is <at> lostca.se (Ashish SHUKLA) > Cc: 13864 <at> 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-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Thu, 07 Mar 2013 10:21:01 GMT) Full text and rfc822 format available.Message #41 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: ashish.is <at> lostca.se (Ashish SHUKLA) To: Eli Zaretskii <eliz <at> gnu.org> Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Thu, 07 Mar 2013 15:49:55 +0530
[Message part 1 (text/plain, inline)]
On Thu, 07 Mar 2013 11:16:18 +0200, Eli Zaretskii <eliz <at> gnu.org> said: >> From: ashish.is <at> lostca.se (Ashish SHUKLA) >> Cc: 13864 <at> 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
[Message part 2 (application/pgp-signature, inline)]
bug-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Thu, 07 Mar 2013 12:50:02 GMT) Full text and rfc822 format available.Message #44 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: ashish.is <at> lostca.se (Ashish SHUKLA) Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Thu, 07 Mar 2013 14:48:20 +0200
> From: ashish.is <at> lostca.se (Ashish SHUKLA) > Cc: 13864 <at> 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-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Fri, 08 Mar 2013 10:10:02 GMT) Full text and rfc822 format available.Message #47 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: ashish.is <at> lostca.se (Ashish SHUKLA) To: Eli Zaretskii <eliz <at> gnu.org> Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Fri, 08 Mar 2013 15:38:30 +0530
[Message part 1 (text/plain, inline)]
On Thu, 07 Mar 2013 14:48:20 +0200, Eli Zaretskii <eliz <at> gnu.org> said: >> From: ashish.is <at> lostca.se (Ashish SHUKLA) >> Cc: 13864 <at> 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
[gdb.txt.xz (application/octet-stream, attachment)]
[Message part 3 (application/pgp-signature, inline)]
bug-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Fri, 08 Mar 2013 16:00:02 GMT) Full text and rfc822 format available.Message #50 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: ashish.is <at> lostca.se (Ashish SHUKLA) Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Fri, 08 Mar 2013 17:58:47 +0200
> From: ashish.is <at> lostca.se (Ashish SHUKLA) > Cc: 13864 <at> 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-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Wed, 13 Mar 2013 09:02:03 GMT) Full text and rfc822 format available.Message #53 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: ashish.is <at> lostca.se (Ashish SHUKLA) To: Eli Zaretskii <eliz <at> gnu.org> Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Wed, 13 Mar 2013 14:30:05 +0530
[Message part 1 (text/plain, inline)]
Hi Eli, Sorry for the delay in follow-up. On Fri, 08 Mar 2013 17:58:47 +0200, Eli Zaretskii <eliz <at> gnu.org> said: >> From: ashish.is <at> lostca.se (Ashish SHUKLA) >> Cc: 13864 <at> 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
[gdb-1.txt.xz (application/octet-stream, attachment)]
[gdb-2.txt.xz (application/octet-stream, attachment)]
[Message part 4 (application/pgp-signature, inline)]
bug-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Fri, 15 Mar 2013 09:41:01 GMT) Full text and rfc822 format available.Message #56 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: ashish.is <at> lostca.se (Ashish SHUKLA) Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Fri, 15 Mar 2013 11:39:34 +0200
> From: ashish.is <at> lostca.se (Ashish SHUKLA) > Cc: 13864 <at> 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-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Fri, 22 Mar 2013 12:48:02 GMT) Full text and rfc822 format available.Message #59 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: ashish.is <at> lostca.se (Ashish SHUKLA) To: Eli Zaretskii <eliz <at> gnu.org> Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Fri, 22 Mar 2013 18:14:22 +0530
[Message part 1 (text/plain, inline)]
On Fri, 15 Mar 2013 11:39:34 +0200, Eli Zaretskii <eliz <at> gnu.org> said: >> From: ashish.is <at> lostca.se (Ashish SHUKLA) >> Cc: 13864 <at> 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
[gdb.txt.xz (application/octet-stream, attachment)]
[Message part 3 (application/pgp-signature, inline)]
bug-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Sun, 24 Mar 2013 19:57:02 GMT) Full text and rfc822 format available.Message #62 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: ashish.is <at> lostca.se (Ashish SHUKLA) Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Sun, 24 Mar 2013 21:54:04 +0200
> From: ashish.is <at> lostca.se (Ashish SHUKLA) > Cc: 13864 <at> 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-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Mon, 25 Mar 2013 09:32:02 GMT) Full text and rfc822 format available.Message #65 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: ashish.is <at> lostca.se (Ashish SHUKLA) To: Eli Zaretskii <eliz <at> gnu.org> Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Mon, 25 Mar 2013 14:58:08 +0530
[Message part 1 (text/plain, inline)]
On Sun, 24 Mar 2013 21:54:04 +0200, Eli Zaretskii <eliz <at> 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
[gdb.txt.xz (application/octet-stream, attachment)]
[Message part 3 (application/pgp-signature, inline)]
bug-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Mon, 25 Mar 2013 10:59:02 GMT) Full text and rfc822 format available.Message #68 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: ashish.is <at> lostca.se (Ashish SHUKLA) Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Mon, 25 Mar 2013 12:56:06 +0200
> From: ashish.is <at> lostca.se (Ashish SHUKLA) > Cc: 13864 <at> 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-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Mon, 01 Apr 2013 16:49:01 GMT) Full text and rfc822 format available.Message #71 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: ashish.is <at> lostca.se (Ashish SHUKLA) To: Eli Zaretskii <eliz <at> gnu.org> Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Mon, 01 Apr 2013 22:15:46 +0530
[Message part 1 (text/plain, inline)]
On Mon, 25 Mar 2013 12:56:06 +0200, Eli Zaretskii <eliz <at> gnu.org> said: >> From: ashish.is <at> lostca.se (Ashish SHUKLA) >> Cc: 13864 <at> 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
[gdb.txt.xz (application/octet-stream, attachment)]
[Message part 3 (application/pgp-signature, inline)]
bug-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Tue, 02 Apr 2013 17:13:02 GMT) Full text and rfc822 format available.Message #74 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: ashish.is <at> lostca.se (Ashish SHUKLA) Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Tue, 02 Apr 2013 20:10:16 +0300
> From: ashish.is <at> lostca.se (Ashish SHUKLA) > Cc: 13864 <at> 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-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Wed, 10 Apr 2013 09:11:03 GMT) Full text and rfc822 format available.Message #77 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: ashish.is <at> lostca.se (Ashish SHUKLA) To: Eli Zaretskii <eliz <at> gnu.org> Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Wed, 10 Apr 2013 14:36:40 +0530
[Message part 1 (text/plain, inline)]
Hi Eli, First of all sorry for the delay in reply. On Tue, 02 Apr 2013 20:10:16 +0300, Eli Zaretskii <eliz <at> gnu.org> said: >> From: ashish.is <at> lostca.se (Ashish SHUKLA) >> Cc: 13864 <at> 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
[Message part 2 (application/pgp-signature, inline)]
bug-gnu-emacs <at> gnu.org
:bug#13864
; Package emacs
.
(Wed, 10 Apr 2013 15:46:01 GMT) Full text and rfc822 format available.Message #80 received at 13864 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: ashish.is <at> lostca.se (Ashish SHUKLA) Cc: 13864 <at> debbugs.gnu.org Subject: Re: bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Date: Wed, 10 Apr 2013 18:41:15 +0300
> From: ashish.is <at> lostca.se (Ashish SHUKLA) > Cc: 13864 <at> 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.
Glenn Morris <rgm <at> gnu.org>
to control <at> debbugs.gnu.org
.
(Fri, 14 Jun 2013 16:41:02 GMT) Full text and rfc822 format available.Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org
.
(Sat, 13 Jul 2013 11:24:04 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.