all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: ashish.is@lostca.se (Ashish SHUKLA)
Cc: 13864@debbugs.gnu.org
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	[thread overview]
Message-ID: <83620t57e1.fsf@gnu.org> (raw)
In-Reply-To: <86sj3zy8ru.fsf@chateau.d.if>

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





  reply	other threads:[~2013-03-15  9:39 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-03 19:19 bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11 Ashish SHUKLA
2013-03-04 17:50 ` Eli Zaretskii
2013-03-04 19:13   ` Ashish SHUKLA
2013-03-04 20:22     ` Eli Zaretskii
2013-03-05  0:26       ` Ashish SHUKLA
2013-03-06 17:07         ` Eli Zaretskii
2013-03-06 18:52           ` Ashish SHUKLA
2013-03-06 21:00             ` Eli Zaretskii
2013-03-07  1:43               ` Ashish SHUKLA
2013-03-07  6:55                 ` Eli Zaretskii
2013-03-07  7:38                   ` Ashish SHUKLA
2013-03-07  9:16                     ` Eli Zaretskii
2013-03-07 10:19                       ` Ashish SHUKLA
2013-03-07 12:48                         ` Eli Zaretskii
2013-03-08 10:08                           ` Ashish SHUKLA
2013-03-08 15:58                             ` Eli Zaretskii
2013-03-13  9:00                               ` Ashish SHUKLA
2013-03-15  9:39                                 ` Eli Zaretskii [this message]
2013-03-22 12:44                                   ` Ashish SHUKLA
2013-03-24 19:54                                     ` Eli Zaretskii
2013-03-25  9:28                                       ` Ashish SHUKLA
2013-03-25 10:56                                         ` Eli Zaretskii
2013-04-01 16:45                                           ` Ashish SHUKLA
2013-04-02 17:10                                             ` Eli Zaretskii
2013-04-10  9:06                                               ` Ashish SHUKLA
2013-04-10 15:41                                                 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83620t57e1.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=13864@debbugs.gnu.org \
    --cc=ashish.is@lostca.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.