[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ashish SHUKLA
Subject: 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
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (amd64-portbld-freebsd9.1)

Hi Eli,

Sorry for the delay in follow-up.

On Fri, 08 Mar 2013 17:58:47 +0200, Eli Zaretskii <address@hidden> said:
>> From: address@hidden (Ashish SHUKLA)
>> Cc: address@hidden
>> 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

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

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

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


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

Sent from my Emacs

Attachment: gdb-1.txt.xz
Description: Binary data

Attachment: gdb-2.txt.xz
Description: Binary data

Attachment: pgpjlDTdckKkr.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]