From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: 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 Message-ID: <83620t57e1.fsf@gnu.org> References: <86y5e4xpd8.fsf@chateau.d.if> <83ehfvt5pp.fsf@gnu.org> <86mwujou60.fsf@chateau.d.if> <83y5e2synt.fsf@gnu.org> <86ip56adz3.fsf@chateau.d.if> <83txoo1mp3.fsf@gnu.org> <868v60743o.fsf@chateau.d.if> <83ppzc1bx9.fsf@gnu.org> <866214m1bh.fsf@chateau.d.if> <838v5z1yx4.fsf@gnu.org> <86mwuf8xrq.fsf@chateau.d.if> <8362131sf1.fsf@gnu.org> <86ip538qb8.fsf@chateau.d.if> <83y5dzz88b.fsf@gnu.org> <868v5y9pb5.fsf@chateau.d.if> <837glhzxvs.fsf@gnu.org> <86sj3zy8ru.fsf@chateau.d.if> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1363340419 23600 80.91.229.3 (15 Mar 2013 09:40:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Mar 2013 09:40:19 +0000 (UTC) Cc: 13864@debbugs.gnu.org To: ashish.is@lostca.se (Ashish SHUKLA) Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 15 10:40:43 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UGR7h-0007P7-9b for geb-bug-gnu-emacs@m.gmane.org; Fri, 15 Mar 2013 10:40:25 +0100 Original-Received: from localhost ([::1]:35264 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGR7K-0005IJ-In for geb-bug-gnu-emacs@m.gmane.org; Fri, 15 Mar 2013 05:40:02 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42042) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGR7D-0005Hc-Sy for bug-gnu-emacs@gnu.org; Fri, 15 Mar 2013 05:40:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UGR75-0003Qd-3U for bug-gnu-emacs@gnu.org; Fri, 15 Mar 2013 05:39:55 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51358) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGR74-0003QO-Qt for bug-gnu-emacs@gnu.org; Fri, 15 Mar 2013 05:39:46 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UGR8I-0006wE-8i for bug-gnu-emacs@gnu.org; Fri, 15 Mar 2013 05:41:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Mar 2013 09:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13864 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13864-submit@debbugs.gnu.org id=B13864.136334045926662 (code B ref 13864); Fri, 15 Mar 2013 09:41:01 +0000 Original-Received: (at 13864) by debbugs.gnu.org; 15 Mar 2013 09:40:59 +0000 Original-Received: from localhost ([127.0.0.1]:55467 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGR8E-0006vx-W5 for submit@debbugs.gnu.org; Fri, 15 Mar 2013 05:40:59 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:63864) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGR8B-0006vg-Fy for 13864@debbugs.gnu.org; Fri, 15 Mar 2013 05:40:57 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MJP0010041GM600@a-mtaout22.012.net.il> for 13864@debbugs.gnu.org; Fri, 15 Mar 2013 11:39:32 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MJP001DO45WDWA0@a-mtaout22.012.net.il>; Fri, 15 Mar 2013 11:39:32 +0200 (IST) In-reply-to: <86sj3zy8ru.fsf@chateau.d.if> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:72523 Archived-At: > 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.