[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 <eliz@gnu.org> said:
>> From: ashish.is@lostca.se (Ashish SHUKLA)
>> Cc: 13864@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
Description: Binary data
gdb-2.txt.xz
Description: Binary data
pgpvtSXKlSagA.pgp
Description: PGP signature
- bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11, (continued)
- bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11, Ashish SHUKLA, 2013/03/06
- bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11, Eli Zaretskii, 2013/03/06
- bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11, Ashish SHUKLA, 2013/03/06
- bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11, Eli Zaretskii, 2013/03/07
- bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11, Ashish SHUKLA, 2013/03/07
- bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11, Eli Zaretskii, 2013/03/07
- bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11, Ashish SHUKLA, 2013/03/07
- bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11, Eli Zaretskii, 2013/03/07
- bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11, Ashish SHUKLA, 2013/03/08
- bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11, Eli Zaretskii, 2013/03/08
- bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11,
Ashish SHUKLA <=
- bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11, Eli Zaretskii, 2013/03/15
- bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11, Ashish SHUKLA, 2013/03/22
- bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11, Eli Zaretskii, 2013/03/24
- bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11, Ashish SHUKLA, 2013/03/25
- bug#13864: 24.3.50; emacsclient -t loops when connected to emacs server running in X11, Eli Zaretskii, 2013/03/25