bug#14616: 24.3.50; Excessive cursor movement on non-X Emacs

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: 14616@debbugs.gnu.org
> Date: Tue, 25 Jun 2013 22:18:55 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Any progress with investigating this?
> >
> > Let me know if you need help.
> 
> I do need help.  I've been trying to follow the advice in the #13864 bug
> report, but the code has shifted quite a bit in the last two months, and
> I know virtually nothing about gdb, I'm afraid.
> 
> Do you have a handy set of commands to start debugging this?

Let's see...  The first set of instructions, at
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13864#20, should still be
a good starting point.  I repeat them below, indented (with one
important correction):

  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) set height 0
   (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 the above is not clear enough, let me know where you want me to
elaborate.  (In case you didn't know, attaching a debugger means
running "gdb -p PID" where PID is the id of the Emacs process.)

The goal of the above is to see whether update_frame_1 is called with
high frequency, so that we could then understand why it is called and
why it redraws the same screen content again and again.

TIA