Need help debugging Emacs: emacsclient will not draw its contents sometimes

Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Jon Dufresne]

Hi,

I run into a bug daily but I can't pin down the exact source of the problem.

I can't reproduce the bug on demand, but if I use Emacs long enough,
eventually the bug will be triggered.

The scenario:

I run Emacs using the Emacs daemon. I regularly connect to the daemon
with emacsclient. Frequently, the client is started from an external
program, such as during a mercurial commit. _Sometimes the emacsclient
frame will not draw its contents_, leaving Emacs in a useless state.
This only occurs after the Emacs daemon has been running for hours and
has already successfully started many emacsclients. When this occurs,
my window manager shows that the program is running and has drawn an
outline of where Emacs should be, but there are no contents. After the
first occurrence, all new emacsclients will suffer the same fate and
will not draw their contents. To Emacs return to a useful state, I
restart the Emacs daemon. This means I lose the open buffers of my
currently running Emacs.

Unfortunately, as I can't reliably reproduce this on demand, it is
difficult and time consuming to tests different versions of init.el.

Emacs version:
GNU Emacs 24.5.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.16.2) of
2015-04-22 on buildhw-10.phx2.fedoraproject.org

I have attached a debugger to the running Emacs after this has
occurred. I see the following backtrace below.

Any help towards debugging this issue would be greatly appreciated.
Please let me know if there is a useful command I can run run to help
diagnose the issue.

(gdb) bt
#0  0x00007f184dcd313c in __pselect (nfds=nfds@entry=15,
readfds=readfds@entry=0x7fff0ba22460,
writefds=writefds@entry=0x7fff0ba224e0, exceptfds=exceptfds@entry=0x0,
timeout=<optimized out>,
    timeout@entry=0x7fff0ba22a80, sigmask=sigmask@entry=0x0) at
../sysdeps/unix/sysv/linux/pselect.c:77
#1  0x00000000005dbeb9 in xg_select (fds_lim=15,
rfds=rfds@entry=0x7fff0ba22aa0, wfds=wfds@entry=0x7fff0ba22b20,
efds=efds@entry=0x0, timeout=timeout@entry=0x7fff0ba22a80,
sigmask=sigmask@entry=0x0)
    at ../../src/xgselect.c:114
#2  0x00000000005a2669 in wait_reading_process_output
(time_limit=time_limit@entry=0, nsecs=nsecs@entry=0,
read_kbd=read_kbd@entry=-1, do_display=true, wait_for_cell=12327986,
wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at
../../src/process.c:4606
#3  0x00000000004f3eb1 in read_decoded_event_from_main_queue
(end_time=0x0, used_mouse_menu=0x7fff0ba232eb, kbp=<synthetic
pointer>) at ../../src/keyboard.c:3907
#4  0x00000000004f3eb1 in read_decoded_event_from_main_queue
(used_mouse_menu=0x7fff0ba232eb, local_getcjmp=0x7fff0ba23040,
end_time=0x0) at ../../src/keyboard.c:2247
#5  0x00000000004f3eb1 in read_decoded_event_from_main_queue
(end_time=end_time@entry=0x0,
local_getcjmp=local_getcjmp@entry=0x7fff0ba23040,
prev_event=prev_event@entry=12327986,
used_mouse_menu=used_mouse_menu@entry=0x7fff0ba232eb) at
../../src/keyboard.c:2310
#6  0x00000000004f7984 in read_char (commandflag=1,
map=map@entry=80441558, prev_event=12327986,
used_mouse_menu=used_mouse_menu@entry=0x7fff0ba232eb,
end_time=end_time@entry=0x0) at ../../src/keyboard.c:2896
#7  0x00000000004f8a48 in read_key_sequence
(keybuf=keybuf@entry=0x7fff0ba233f0, prompt=12327986,
dont_downcase_last=dont_downcase_last@entry=false,
can_return_switch_frame=can_return_switch_frame@entry=true,
fix_current_buffer=fix_current_buffer@entry=true,
prevent_redisplay=prevent_redisplay@entry=false, bufsize=30) at
../../src/keyboard.c:9089
#8  0x00000000004fa84e in command_loop_1 () at ../../src/keyboard.c:1453
#9  0x000000000055fd47 in internal_condition_case
(bfun=bfun@entry=0x4fa630 <command_loop_1>, handlers=<optimized out>,
hfun=hfun@entry=0x4f1180 <cmd_error>) at ../../src/eval.c:1348
#10 0x00000000004ec602 in command_loop_2
(ignore=ignore@entry=12327986) at ../../src/keyboard.c:1178
#11 0x000000000055fc2b in internal_catch (tag=12375458,
func=func@entry=0x4ec5e0 <command_loop_2>, arg=12327986) at
../../src/eval.c:1112
#12 0x00000000004f0d43 in recursive_edit_1 () at ../../src/keyboard.c:1157
#13 0x00000000004f0d43 in recursive_edit_1 () at ../../src/keyboard.c:778
#14 0x00000000004f1098 in Frecursive_edit () at ../../src/keyboard.c:849
#15 0x0000000000418537 in main (argc=<optimized out>,
argv=0x7fff0ba23758) at ../../src/emacs.c:1642

(gdb) bt
#0  0x00007f67c0942a0d in __libc_recv (fd=3,
buf=buf@entry=0x7fffb54676b0, n=n@entry=8192, flags=flags@entry=0) at
../sysdeps/unix/sysv/linux/x86_64/recv.c:29
#1  0x0000000000401ce0 in recv (__flags=0, __n=8192,
__buf=0x7fffb54676b0, __fd=<optimized out>) at
/usr/include/bits/socket2.h:44
#2  main (argc=3, argv=0x7fffb54697d8) at ../../lib-src/emacsclient.c:1742

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Tassilo Horn]

Jon Dufresne <jon.dufresne@gmail.com> writes:

Hi Jon,

> _Sometimes the emacsclient frame will not draw its contents_, leaving
> Emacs in a useless state.  This only occurs after the Emacs daemon has
> been running for hours and has already successfully started many
> emacsclients. When this occurs, my window manager shows that the
> program is running and has drawn an outline of where Emacs should be,
> but there are no contents.

Oh, last week I had that situation, too.  I executed "emacsclient -c
file" on the command line and apparently nothing happened.  I'm not
exactly sure anymore but I think there were not even window decorations.
However, when I entered the Gnome 3 overview where you get a quick
preview of all your X windows, one empty emacs frame was shown.

> After the first occurrence, all new emacsclients will suffer the same
> fate and will not draw their contents.  To Emacs return to a useful
> state, I restart the Emacs daemon.  This means I lose the open buffers
> of my currently running Emacs.

That's different to my case.  I think I could quit the problematic
window from the Gnome 3 overview which also made emacsclient return, and
then the same invocation again resulted in a correctly drawn window.

But that occurred only exactly once so far and I have no receipe, too.
In contrast to Jon, I don't run emacs as a daemon but I have

  (unless (server-running-p)
    (server-start))

in my ~/.emacs.

Bye,
Tassilo

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Eli Zaretskii]

> Date: Tue, 8 Sep 2015 06:00:25 -0700
> From: Jon Dufresne <jon.dufresne@gmail.com>
> 
> I run Emacs using the Emacs daemon. I regularly connect to the daemon
> with emacsclient. Frequently, the client is started from an external
> program, such as during a mercurial commit. _Sometimes the emacsclient
> frame will not draw its contents_, leaving Emacs in a useless state.
> This only occurs after the Emacs daemon has been running for hours and
> has already successfully started many emacsclients. When this occurs,
> my window manager shows that the program is running and has drawn an
> outline of where Emacs should be, but there are no contents. After the
> first occurrence, all new emacsclients will suffer the same fate and
> will not draw their contents. To Emacs return to a useful state, I
> restart the Emacs daemon. This means I lose the open buffers of my
> currently running Emacs.
> 
> Unfortunately, as I can't reliably reproduce this on demand, it is
> difficult and time consuming to tests different versions of init.el.
> 
> Emacs version:
> GNU Emacs 24.5.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.16.2) of
> 2015-04-22 on buildhw-10.phx2.fedoraproject.org
> 
> I have attached a debugger to the running Emacs after this has
> occurred. I see the following backtrace below.

The backtrace shows that Emacs is idle, waiting for input, which is
normal.  Try typing "finish" repeatedly to step out of the functions
shown in the backtrace, until some of them doesn't return.  Then tell
here which one didn't.

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Jon Dufresne]

On Tue, Sep 8, 2015 at 10:18 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> The backtrace shows that Emacs is idle, waiting for input, which is
> normal.  Try typing "finish" repeatedly to step out of the functions
> shown in the backtrace, until some of them doesn't return.  Then tell
> here which one didn't.

Thanks!

I have tried this. The results are below. The client process hung on
the first "finish" while the server process took a few more commands
but eventually hung in command_loop_1(). Any thoughts on this?

Cheers,
Jon


Client:
(gdb) bt
#0  0x00000030d8b03a0d in __libc_recv (fd=3,
buf=buf@entry=0x7ffd1328bf60, n=n@entry=8192, flags=flags@entry=0) at
../sysdeps/unix/sysv/linux/x86_64/recv.c:29
#1  0x0000000000401ce0 in recv (__flags=0, __n=8192,
__buf=0x7ffd1328bf60, __fd=<optimized out>) at
/usr/include/bits/socket2.h:44
#2  main (argc=3, argv=0x7ffd1328e088) at ../../lib-src/emacsclient.c:1742
(gdb) finish
Run till exit from #0  0x00000030d8b03a0d in __libc_recv (fd=3,
buf=buf@entry=0x7ffd1328bf60, n=n@entry=8192, flags=flags@entry=0) at
../sysdeps/unix/sysv/linux/x86_64/recv.c:29


Server:
(gdb) bt
#0  0x00000030d8af913c in __pselect (nfds=nfds@entry=17,
readfds=readfds@entry=0x7ffdd014e210,
writefds=writefds@entry=0x7ffdd014e290, exceptfds=exceptfds@entry=0x0,
timeout=<optimized out>, timeout@entry=0x7ffdd014e830,
sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/pselect.c:77
#1  0x00000000005dbeb9 in xg_select (fds_lim=17,
rfds=rfds@entry=0x7ffdd014e850, wfds=wfds@entry=0x7ffdd014e8d0,
efds=efds@entry=0x0, timeout=timeout@entry=0x7ffdd014e830,
sigmask=sigmask@entry=0x0) at ../../src/xgselect.c:114
#2  0x00000000005a2669 in wait_reading_process_output
(time_limit=time_limit@entry=0, nsecs=nsecs@entry=0,
read_kbd=read_kbd@entry=-1, do_display=true, wait_for_cell=12327986,
wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at
../../src/process.c:4606
#3  0x00000000004f3eb1 in read_decoded_event_from_main_queue
(end_time=0x0, used_mouse_menu=0x7ffdd014f09b, kbp=<synthetic
pointer>) at ../../src/keyboard.c:3907
#4  0x00000000004f3eb1 in read_decoded_event_from_main_queue
(used_mouse_menu=0x7ffdd014f09b, local_getcjmp=0x7ffdd014edf0,
end_time=0x0) at ../../src/keyboard.c:2247
#5  0x00000000004f3eb1 in read_decoded_event_from_main_queue
(end_time=end_time@entry=0x0,
local_getcjmp=local_getcjmp@entry=0x7ffdd014edf0,
prev_event=prev_event@entry=12327986,
used_mouse_menu=used_mouse_menu@entry=0x7ffdd014f09b) at
../../src/keyboard.c:2310
#6  0x00000000004f7984 in read_char (commandflag=1,
map=map@entry=63963270, prev_event=12327986,
used_mouse_menu=used_mouse_menu@entry=0x7ffdd014f09b,
end_time=end_time@entry=0x0)
    at ../../src/keyboard.c:2896
#7  0x00000000004f8a48 in read_key_sequence
(keybuf=keybuf@entry=0x7ffdd014f1a0, prompt=12327986,
dont_downcase_last=dont_downcase_last@entry=false,
can_return_switch_frame=can_return_switch_frame@entry=true,
fix_current_buffer=fix_current_buffer@entry=true,
prevent_redisplay=prevent_redisplay@entry=false, bufsize=30) at
../../src/keyboard.c:9089
#8  0x00000000004fa84e in command_loop_1 () at ../../src/keyboard.c:1453
#9  0x000000000055fd47 in internal_condition_case
(bfun=bfun@entry=0x4fa630 <command_loop_1>, handlers=<optimized out>,
hfun=hfun@entry=0x4f1180 <cmd_error>) at ../../src/eval.c:1348
#10 0x00000000004ec602 in command_loop_2
(ignore=ignore@entry=12327986) at ../../src/keyboard.c:1178
#11 0x000000000055fc2b in internal_catch (tag=12375458,
func=func@entry=0x4ec5e0 <command_loop_2>, arg=12327986) at
../../src/eval.c:1112
#12 0x00000000004f0d43 in recursive_edit_1 () at ../../src/keyboard.c:1157
#13 0x00000000004f0d43 in recursive_edit_1 () at ../../src/keyboard.c:778
#14 0x00000000004f1098 in Frecursive_edit () at ../../src/keyboard.c:849
#15 0x0000000000418537 in main (argc=<optimized out>,
argv=0x7ffdd014f508) at ../../src/emacs.c:1642
(gdb) finish
Run till exit from #0  0x00000030d8af913c in __pselect
(nfds=nfds@entry=17, readfds=readfds@entry=0x7ffdd014e210,
writefds=writefds@entry=0x7ffdd014e290, exceptfds=exceptfds@entry=0x0,
    timeout=<optimized out>, timeout@entry=0x7ffdd014e830,
sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/pselect.c:77
xg_select (fds_lim=17, rfds=rfds@entry=0x7ffdd014e850,
wfds=wfds@entry=0x7ffdd014e8d0, efds=efds@entry=0x0,
timeout=timeout@entry=0x7ffdd014e830, sigmask=sigmask@entry=0x0)
    at ../../src/xgselect.c:117
117      if (nfds < 0)
Value returned is $1 = 0
(gdb) finish
Run till exit from #0  xg_select (fds_lim=17,
rfds=rfds@entry=0x7ffdd014e850, wfds=wfds@entry=0x7ffdd014e8d0,
efds=efds@entry=0x0, timeout=timeout@entry=0x7ffdd014e830,
    sigmask=sigmask@entry=0x0) at ../../src/xgselect.c:117
wait_reading_process_output (time_limit=time_limit@entry=0,
nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=true,
wait_for_cell=12327986, wait_proc=wait_proc@entry=0x0,
    just_wait_proc=0) at ../../src/process.c:4620
4620              if (nfds == 0)
Value returned is $2 = 0
(gdb) finish
Run till exit from #0  wait_reading_process_output
(time_limit=time_limit@entry=0, nsecs=nsecs@entry=0,
read_kbd=read_kbd@entry=-1, do_display=true, wait_for_cell=12327986,
    wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at ../../src/process.c:4620
0x00000000004f3eb1 in kbd_buffer_get_event (end_time=0x0,
used_mouse_menu=0x7ffdd014f09b, kbp=<synthetic pointer>) at
../../src/keyboard.c:3907
3907          wait_reading_process_output (0, 0, -1, do_display, Qnil, NULL, 0);
Value returned is $3 = true
(gdb) finish
Run till exit from #0  0x00000000004f3eb1 in kbd_buffer_get_event
(end_time=0x0, used_mouse_menu=0x7ffdd014f09b, kbp=<synthetic
pointer>) at ../../src/keyboard.c:3907
2247      c = kbd_buffer_get_event (&kb, used_mouse_menu, end_time);
(gdb) finish
Run till exit from #0  read_event_from_main_queue
(used_mouse_menu=0x7ffdd014f09b, local_getcjmp=0x7ffdd014edf0,
end_time=0x0) at ../../src/keyboard.c:2247
2320          struct frame *frame = XFRAME (selected_frame);
(gdb) finish
Run till exit from #0  read_decoded_event_from_main_queue
(end_time=end_time@entry=0x0,
local_getcjmp=local_getcjmp@entry=0x7ffdd014edf0,
prev_event=prev_event@entry=12327986,
    used_mouse_menu=used_mouse_menu@entry=0x7ffdd014f09b) at
../../src/keyboard.c:2320
read_char (commandflag=1, map=map@entry=63963270, prev_event=12327986,
used_mouse_menu=used_mouse_menu@entry=0x7ffdd014f09b,
end_time=end_time@entry=0x0) at ../../src/keyboard.c:2898
2898          if (NILP(c) && end_time &&
Value returned is $4 = 75183542
(gdb) finish
Run till exit from #0  read_char (commandflag=1,
map=map@entry=63963270, prev_event=12327986,
used_mouse_menu=used_mouse_menu@entry=0x7ffdd014f09b,
end_time=end_time@entry=0x0)
    at ../../src/keyboard.c:2898
0x00000000004f8a48 in read_key_sequence
(keybuf=keybuf@entry=0x7ffdd014f1a0, prompt=12327986,
dont_downcase_last=dont_downcase_last@entry=false,
    can_return_switch_frame=can_return_switch_frame@entry=true,
fix_current_buffer=fix_current_buffer@entry=true,
prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
    at ../../src/keyboard.c:9089
9089            key = read_char (prevent_redisplay ? -2 : NILP (prompt),
Value returned is $5 = 75183542
(gdb) finish
Run till exit from #0  0x00000000004f8a48 in read_key_sequence
(keybuf=keybuf@entry=0x7ffdd014f1a0, prompt=12327986,
dont_downcase_last=dont_downcase_last@entry=false,
    can_return_switch_frame=can_return_switch_frame@entry=true,
fix_current_buffer=fix_current_buffer@entry=true,
prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
    at ../../src/keyboard.c:9089
0x00000000004fa84e in command_loop_1 () at ../../src/keyboard.c:1453
1453          i = read_key_sequence (keybuf, sizeof keybuf / sizeof keybuf[0],
Value returned is $6 = 1
(gdb) finish
Run till exit from #0  0x00000000004fa84e in command_loop_1 () at
../../src/keyboard.c:1453

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Eli Zaretskii]

> Date: Tue, 8 Sep 2015 11:58:35 -0700
> From: Jon Dufresne <jon.dufresne@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> On Tue, Sep 8, 2015 at 10:18 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > The backtrace shows that Emacs is idle, waiting for input, which is
> > normal.  Try typing "finish" repeatedly to step out of the functions
> > shown in the backtrace, until some of them doesn't return.  Then tell
> > here which one didn't.
> 
> Thanks!
> 
> I have tried this. The results are below. The client process hung on
> the first "finish" while the server process took a few more commands
> but eventually hung in command_loop_1(). Any thoughts on this?

The "hang" in command_loop_1 is not a hang -- that's the main loop
where Emacs does its job.

So now the question is why you don't see the display.  Please step
through command_loop_1 until it calls read_key_sequence, step into
that, then step until it calls read_char, and step through read_char
until it calls redisplay_internal.  Once you are inside
redisplay_internal, step through it and show which lines are being
executed.

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Jon Dufresne]

On Tue, Sep 8, 2015 at 12:16 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> So now the question is why you don't see the display.  Please step
> through command_loop_1 until it calls read_key_sequence, step into
> that, then step until it calls read_char, and step through read_char
> until it calls redisplay_internal.  Once you are inside
> redisplay_internal, step through it and show which lines are being
> executed.

Thanks. I'm no expert on gdb, but I believe I have followed your
suggestion. Below is the output from gdb by stepping through
redisplay_internal from beginning to end. Let me know what you think.
Any insight as to why the contents are not drawn?

(gdb) n
redisplay_internal () at ../../src/xdisp.c:13482
13482    {
(gdb) n
13507      if (FRAME_INITIAL_P (SELECTED_FRAME ())
(gdb) n
2430      if (! VECTORLIKEP (a))
(gdb) n
704    LISP_MACRO_DEFUN (XUNTAG, void *, (Lisp_Object a, int type), (a, type))
(gdb) n
13507      if (FRAME_INITIAL_P (SELECTED_FRAME ())
(gdb) n
13508          || !NILP (Vinhibit_redisplay))
(gdb) n
13483      struct window *w = XWINDOW (selected_window);
(gdb) n
13517      if (!fr->glyphs_initialized_p)
(gdb) n
13521      if (popup_activated ())
(gdb) n
13526      if (redisplaying_p)
(gdb) n
2894      return specpdl_ptr - specpdl;
(gdb) n
13532      record_unwind_protect_void (unwind_redisplay);
(gdb) n
2894      return specpdl_ptr - specpdl;
(gdb) n
13532      record_unwind_protect_void (unwind_redisplay);
(gdb) n
13534      specbind (Qinhibit_free_realized_faces, Qnil);
(gdb) n
13533      redisplaying_p = 1;
(gdb) n
13534      specbind (Qinhibit_free_realized_faces, Qnil);
(gdb) n
13537      record_in_backtrace (Qredisplay_internal, &Qnil, 0);
(gdb) n
13539      FOR_EACH_FRAME (tail, frame)
(gdb) n
13540        XFRAME (frame)->already_hscrolled_p = 0;
(gdb) n
13539      FOR_EACH_FRAME (tail, frame)
(gdb) n
13540        XFRAME (frame)->already_hscrolled_p = 0;
(gdb) n
13539      FOR_EACH_FRAME (tail, frame)
(gdb) n
13540        XFRAME (frame)->already_hscrolled_p = 0;
(gdb) n
13539      FOR_EACH_FRAME (tail, frame)
(gdb) n
11650          init_iterator (&it, XWINDOW (f->selected_window), -1, -1,
(gdb) n
14044          STOP_POLLING;
(gdb) n
11650          init_iterator (&it, XWINDOW (f->selected_window), -1, -1,
(gdb) n
13555      if (face_change_count)
(gdb) n
13547      last_escape_glyph_frame = NULL;
(gdb) n
13548      last_escape_glyph_face_id = (1 << FACE_ID_BITS);
(gdb) n
13549      last_glyphless_glyph_frame = NULL;
(gdb) n
13550      last_glyphless_glyph_face_id = (1 << FACE_ID_BITS);
(gdb) n
13555      if (face_change_count)
(gdb) n
13558      if ((FRAME_TERMCAP_P (sf) || FRAME_MSDOS_P (sf))
(gdb) n
13576      FOR_EACH_FRAME (tail, frame)
(gdb) n
704    LISP_MACRO_DEFUN (XUNTAG, void *, (Lisp_Object a, int type), (a, type))
(gdb) n
13580          if (FRAME_VISIBLE_P (f))
(gdb) n
13582          ++number_of_visible_frames;
(gdb) n
13584          if (f->fonts_changed)
(gdb) n
13591          if (f != sf && f->cursor_type_changed)
(gdb) n
13594          clear_desired_matrices (f);
(gdb) n
13576      FOR_EACH_FRAME (tail, frame)
(gdb) n
704    LISP_MACRO_DEFUN (XUNTAG, void *, (Lisp_Object a, int type), (a, type))
(gdb) n
13580          if (FRAME_VISIBLE_P (f))
(gdb) n
13582          ++number_of_visible_frames;
(gdb) n
13584          if (f->fonts_changed)
(gdb) n
13591          if (f != sf && f->cursor_type_changed)
(gdb) n
13594          clear_desired_matrices (f);
(gdb) n
13576      FOR_EACH_FRAME (tail, frame)
(gdb) n
704    LISP_MACRO_DEFUN (XUNTAG, void *, (Lisp_Object a, int type), (a, type))
(gdb) n
13580          if (FRAME_VISIBLE_P (f))
(gdb) n
13582          ++number_of_visible_frames;
(gdb) n
13584          if (f->fonts_changed)
(gdb) n
13591          if (f != sf && f->cursor_type_changed)
(gdb) n
13594          clear_desired_matrices (f);
(gdb) n
13576      FOR_EACH_FRAME (tail, frame)
(gdb) n
13598      do_pending_window_change (1);
(gdb) n
13602      if (WINDOWP (selected_window) && (w = XWINDOW
(selected_window)) != sw)
(gdb) n
2430      if (! VECTORLIKEP (a))
(gdb) n
13602      if (WINDOWP (selected_window) && (w = XWINDOW
(selected_window)) != sw)
(gdb) n
704    LISP_MACRO_DEFUN (XUNTAG, void *, (Lisp_Object a, int type), (a, type))
(gdb) n
11236      if (frame_garbaged)
(gdb) n
13609      if (NILP (Vmemory_full))
(gdb) n
11689      bool all_windows = windows_or_buffers_changed || update_mode_lines;
(gdb) n
11690      bool some_windows = REDISPLAY_SOME_P ();
(gdb) n
11695      tooltip_frame = tip_frame;
(gdb) n
11700      if (FUNCTIONP (Vpre_redisplay_function))
(gdb) n
11695      tooltip_frame = tip_frame;
(gdb) n
703    LISP_MACRO_DEFUN (XTYPE, enum Lisp_Type, (Lisp_Object a), (a))
(gdb) n
4569      if (SYMBOLP (object) && !NILP (Ffboundp (object)))
(gdb) n
2430      if (! VECTORLIKEP (a))
(gdb) n
2422      return ((a->size & (PSEUDOVECTOR_FLAG | PVEC_TYPE_MASK))
(gdb) n
4585      if (SUBRP (object))
(gdb) n
4587      else if (COMPILEDP (object))
(gdb) n
11702          Lisp_Object windows = all_windows ? Qt : Qnil;
(gdb) n
11718          safe__call1 (true, Vpre_redisplay_function, windows);
(gdb) n
11725      if (all_windows)
(gdb) n
11817          struct frame *sf = SELECTED_FRAME ();
(gdb) n
2430      if (! VECTORLIKEP (a))
(gdb) n
11817          struct frame *sf = SELECTED_FRAME ();
(gdb) n
704    LISP_MACRO_DEFUN (XUNTAG, void *, (Lisp_Object a, int type), (a, type))
(gdb) n
11817          struct frame *sf = SELECTED_FRAME ();
(gdb) n
11846      if (inhibit_menubar_update)
(gdb) n
11977      if (do_update)
(gdb) n
13612      reconsider_clip_changes (w);
(gdb) n
704    LISP_MACRO_DEFUN (XUNTAG, void *, (Lisp_Object a, int type), (a, type))
(gdb) n
13615      match_p = XBUFFER (w->contents) == current_buffer;
(gdb) n
704    LISP_MACRO_DEFUN (XUNTAG, void *, (Lisp_Object a, int type), (a, type))
(gdb) n
13615      match_p = XBUFFER (w->contents) == current_buffer;
(gdb) n
13616      if (match_p)
(gdb) n
13619          if ((SAVE_MODIFF < MODIFF) != w->last_had_star)
(gdb) n
13622          if (mode_line_update_needed (w))
(gdb) n
13628          if (current_buffer->clip_changed)
(gdb) n
13637      if ((!NILP (echo_area_buffer[0]) &&
!display_last_displayed_message_p)
(gdb) n
13645          int window_height_changed_p = echo_area_display (0);
(gdb) n
13648        update_miniwindow_p = true;
(gdb) n
13656          if (!display_last_displayed_message_p)
(gdb) n
13648        update_miniwindow_p = true;
(gdb) n
13656          if (!display_last_displayed_message_p)
(gdb) n
13657        message_cleared_p = 0;
(gdb) n
13659          if (window_height_changed_p)
(gdb) n
13650          must_finish = 1;
(gdb) n
13683      if (windows_or_buffers_changed && !update_mode_lines)
(gdb) n
13692      if (overlay_arrows_changed_p ())
(gdb) n
13697      consider_all_windows_p = (update_mode_lines
(gdb) n
13698                    || windows_or_buffers_changed);
(gdb) n
13704      AINC (Vredisplay__all_windows_cause, windows_or_buffers_changed);
(gdb) n
2394      return VECTORLIKEP (x) && ! (ASIZE (x) & PSEUDOVECTOR_FLAG);
(gdb) n
1368      return XVECTOR (array)->header.size;
(gdb) n
704    LISP_MACRO_DEFUN (XUNTAG, void *, (Lisp_Object a, int type), (a, type))
(gdb) n
2394      return VECTORLIKEP (x) && ! (ASIZE (x) & PSEUDOVECTOR_FLAG);
(gdb) n
13704      AINC (Vredisplay__all_windows_cause, windows_or_buffers_changed);
(gdb) n
13705      AINC (Vredisplay__mode_lines_cause, update_mode_lines);
(gdb) n
2394      return VECTORLIKEP (x) && ! (ASIZE (x) & PSEUDOVECTOR_FLAG);
(gdb) n
704    LISP_MACRO_DEFUN (XUNTAG, void *, (Lisp_Object a, int type), (a, type))
(gdb) n
1368      return XVECTOR (array)->header.size;
(gdb) n
13705      AINC (Vredisplay__mode_lines_cause, update_mode_lines);
(gdb) n
13711      tlbufpos = this_line_start_pos;
(gdb) n
13714          && CHARPOS (tlbufpos) > 0
(gdb) n
13715          && !w->update_mode_line
(gdb) n
13716          && !current_buffer->clip_changed
(gdb) n
13717          && !current_buffer->prevent_redisplay_optimizations_p
(gdb) n
13718          && FRAME_VISIBLE_P (XFRAME (w->frame))
(gdb) n
13719          && !FRAME_OBSCURED_P (XFRAME (w->frame))
(gdb) n
13720          && !XFRAME (w->frame)->cursor_type_changed
(gdb) n
13723          && match_p
(gdb) n
13724          && !w->force_start
(gdb) n
13725          && !w->optional_new_start
(gdb) n
13727          && PT >= CHARPOS (tlbufpos)
(gdb) n
13728          && PT <= Z - CHARPOS (tlendpos)
(gdb) n
13712      tlendpos = this_line_end_pos;
(gdb) n
13728          && PT <= Z - CHARPOS (tlendpos)
(gdb) n
13712      tlendpos = this_line_end_pos;
(gdb) n
13166      if (window_outdated (w))
(gdb) n
13711      tlbufpos = this_line_start_pos;
(gdb) n
13712      tlendpos = this_line_end_pos;
(gdb) n
13166      if (window_outdated (w))
(gdb) n
13734          if (CHARPOS (tlbufpos) > BEGV
(gdb) n
13735          && FETCH_BYTE (BYTEPOS (tlbufpos) - 1) != '\n'
(gdb) n
13740          else if (window_outdated (w) || MINI_WINDOW_P (w))
(gdb) n
13842          else if (/* Cursor position hasn't changed.  */
(gdb) n
13848               && 0 <= w->cursor.vpos
(gdb) n
13849               && w->cursor.vpos < WINDOW_TOTAL_LINES (w))
(gdb) n
13851          if (!must_finish)
(gdb) n
14036          if (sf->fonts_changed)
(gdb) n
14042          if (interrupt_input)
(gdb) n
14043        unrequest_sigio ();
(gdb) n
14044          STOP_POLLING;
(gdb) n
14046          if (FRAME_VISIBLE_P (sf) && !FRAME_OBSCURED_P (sf))
(gdb) n
14048          if (hscroll_windows (selected_window))
(gdb) n
13078      int hscrolled_p = hscroll_window_tree (window);
(gdb) n
13079      if (hscrolled_p)
(gdb) n
14051          XWINDOW (selected_window)->must_be_updated_p = true;
(gdb) n
14052          pending = update_frame (sf, 0, 0);
(gdb) n
14051          XWINDOW (selected_window)->must_be_updated_p = true;
(gdb) n
14052          pending = update_frame (sf, 0, 0);
(gdb) n
14061          mini_window = FRAME_MINIBUF_WINDOW (sf);
(gdb) n
14053          sf->cursor_type_changed = 0;
(gdb) n
14052          pending = update_frame (sf, 0, 0);
(gdb) n
704    LISP_MACRO_DEFUN (XUNTAG, void *, (Lisp_Object a, int type), (a, type))
(gdb) n
14064          if (mini_frame != sf && FRAME_WINDOW_P (mini_frame))
(gdb) n
14076      if (pending)
(gdb) n
14094          if (!consider_all_windows_p)
(gdb) n
704    LISP_MACRO_DEFUN (XUNTAG, void *, (Lisp_Object a, int type), (a, type))
(gdb) n
14098          if (XBUFFER (w->contents)->text->redisplay
(gdb) n
704    LISP_MACRO_DEFUN (XUNTAG, void *, (Lisp_Object a, int type), (a, type))
(gdb) n
14098          if (XBUFFER (w->contents)->text->redisplay
(gdb) n
14103          mark_window_display_accurate_1 (w, 1);
(gdb) n
14106          update_overlay_arrows (1);
(gdb) n
14108          if (FRAME_TERMINAL (sf)->frame_up_to_date_hook != 0)
(gdb) n
14109            FRAME_TERMINAL (sf)->frame_up_to_date_hook (sf);
(gdb) n
14112          update_mode_lines = 0;
(gdb) n
14113          windows_or_buffers_changed = 0;
(gdb) n
14120      if (interrupt_input)
(gdb) n
14121        request_sigio ();
(gdb) n
14122      RESUME_POLLING;
(gdb) n
14130      if (!pending)
(gdb) n
14134          FOR_EACH_FRAME (tail, frame)
(gdb) n
14136          if (XFRAME (frame)->visible)
(gdb) n
14134          FOR_EACH_FRAME (tail, frame)
(gdb) n
14136          if (XFRAME (frame)->visible)
(gdb) n
14137            new_count++;
(gdb) n
14134          FOR_EACH_FRAME (tail, frame)
(gdb) n
14137            new_count++;
(gdb) n
14134          FOR_EACH_FRAME (tail, frame)
(gdb) n
14136          if (XFRAME (frame)->visible)
(gdb) n
14134          FOR_EACH_FRAME (tail, frame)
(gdb) n
14136          if (XFRAME (frame)->visible)
(gdb) n
14137            new_count++;
(gdb) n
14134          FOR_EACH_FRAME (tail, frame)
(gdb) n
14137            new_count++;
(gdb) n
14134          FOR_EACH_FRAME (tail, frame)
(gdb) n
14136          if (XFRAME (frame)->visible)
(gdb) n
14134          FOR_EACH_FRAME (tail, frame)
(gdb) n
14136          if (XFRAME (frame)->visible)
(gdb) n
14137            new_count++;
(gdb) n
14134          FOR_EACH_FRAME (tail, frame)
(gdb) n
14137            new_count++;
(gdb) n
14134          FOR_EACH_FRAME (tail, frame)
(gdb) n
14140          if (new_count != number_of_visible_frames)
(gdb) n
14145      do_pending_window_change (1);
(gdb) n
14149      if ((windows_or_buffers_changed && !pending)
(gdb) n
14150          || (WINDOWP (selected_window) && (w = XWINDOW
(selected_window)) != sw))
(gdb) n
2430      if (! VECTORLIKEP (a))
(gdb) n
14150          || (WINDOWP (selected_window) && (w = XWINDOW
(selected_window)) != sw))
(gdb) n
704    LISP_MACRO_DEFUN (XUNTAG, void *, (Lisp_Object a, int type), (a, type))
(gdb) n
14150          || (WINDOWP (selected_window) && (w = XWINDOW
(selected_window)) != sw))
(gdb) n
14159      if (clear_face_cache_count > CLEAR_FACE_CACHE_COUNT)
(gdb) n
14166      if (clear_image_cache_count > CLEAR_IMAGE_CACHE_COUNT)
(gdb) n
14177      if (interrupt_input && interrupts_deferred)
(gdb) n
14180      unbind_to (count, Qnil);
(gdb) n
14182    }
(gdb) n
read_char (commandflag=1, map=map@entry=87871094, prev_event=12327986,
used_mouse_menu=used_mouse_menu@entry=0x7fff013f585b,
end_time=end_time@entry=0x0) at ../../src/keyboard.c:2822
2822          if (!detect_input_pending_run_timers (0))
(gdb)

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Eli Zaretskii]

> Date: Wed, 9 Sep 2015 15:29:18 -0700
> From: Jon Dufresne <jon.dufresne@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> On Tue, Sep 8, 2015 at 12:16 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > So now the question is why you don't see the display.  Please step
> > through command_loop_1 until it calls read_key_sequence, step into
> > that, then step until it calls read_char, and step through read_char
> > until it calls redisplay_internal.  Once you are inside
> > redisplay_internal, step through it and show which lines are being
> > executed.
> 
> Thanks. I'm no expert on gdb, but I believe I have followed your
> suggestion. Below is the output from gdb by stepping through
> redisplay_internal from beginning to end. Let me know what you think.
> Any insight as to why the contents are not drawn?

This shows that Emacs examined the frames and windows, and decided
that nothing requires to be redrawn.  Most redisplay cycles are like
that, so this trace doesn't yet point to any problem.

If you type "M-x" into the (empty, AFAIU) client frame, does Emacs
display the "M-x" prompt?  Does it also redisplay some of the frame?
What happens if you type "M-x redraw-display RET"? does Emacs display
anything?

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Jon Dufresne]

On Thu, Sep 10, 2015 at 8:26 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> This shows that Emacs examined the frames and windows, and decided
> that nothing requires to be redrawn.  Most redisplay cycles are like
> that, so this trace doesn't yet point to any problem.

For clarification on what I see, see the image: https://i.imgur.com/HWrwtUm.png

>
> If you type "M-x" into the (empty, AFAIU) client frame, does Emacs
> display the "M-x" prompt?

In the empty frame, no.

I sometimes also have an existing client frame that continues to work
normally. Typing M-x into this frame works normally.

>  Does it also redisplay some of the frame?

No.

> What happens if you type "M-x redraw-display RET"? does Emacs display
> anything?

Nothing. This is true if I type "M-x redraw-display RET" with the
drawn frame focused or the non-drawn frame focused. Would it help to
set a breakpoint before typing this command? If so where would you
expect something interesting?

Cheers,
Jon

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Eli Zaretskii]

> Date: Thu, 10 Sep 2015 11:20:20 -0700
> From: Jon Dufresne <jon.dufresne@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> On Thu, Sep 10, 2015 at 8:26 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > This shows that Emacs examined the frames and windows, and decided
> > that nothing requires to be redrawn.  Most redisplay cycles are like
> > that, so this trace doesn't yet point to any problem.
> 
> For clarification on what I see, see the image: https://i.imgur.com/HWrwtUm.png

Is the background of the frame correct?  That is, if it were
completely displayed, would you expect the background color to remain
as it is shown in that screenshot?

> > What happens if you type "M-x redraw-display RET"? does Emacs display
> > anything?
> 
> Nothing. This is true if I type "M-x redraw-display RET" with the
> drawn frame focused or the non-drawn frame focused. Would it help to
> set a breakpoint before typing this command? If so where would you
> expect something interesting?

I will need to think a bit about that.

Thanks for the info.

Do you have a way to try this with a development snapshot of Emacs 25?

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Jon Dufresne]

On Thu, Sep 10, 2015 at 11:46 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> Is the background of the frame correct?  That is, if it were
> completely displayed, would you expect the background color to remain
> as it is shown in that screenshot?

No. I expect the background of the frame to be white. The color you
see is from the desktop background going through a transparent outline
of where Emacs should be. This screenshot is from the overview of
GNOME 3.

> Do you have a way to try this with a development snapshot of Emacs 25?

I'll give this a shot and report if I encounter the issue again. Thanks.

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Eli Zaretskii]

> Date: Thu, 10 Sep 2015 11:52:03 -0700
> From: Jon Dufresne <jon.dufresne@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> On Thu, Sep 10, 2015 at 11:46 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > Is the background of the frame correct?  That is, if it were
> > completely displayed, would you expect the background color to remain
> > as it is shown in that screenshot?
> 
> No. I expect the background of the frame to be white. The color you
> see is from the desktop background going through a transparent outline
> of where Emacs should be. This screenshot is from the overview of
> GNOME 3.
> 
> > Do you have a way to try this with a development snapshot of Emacs 25?
> 
> I'll give this a shot and report if I encounter the issue again. Thanks.

Thanks.

One other thing to try is "emacsclient -t", i.e. a text-mode frame.
Does that have the same problem, or does it display buffers as
expected?

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Jon Dufresne]

>> Do you have a way to try this with a development snapshot of Emacs 25?

> I'll give this a shot and report if I encounter the issue again. Thanks.1

After some hours of usage today, the issue was reproduced with a
recent git checkout of Emacs:

"M-x version RET"
GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.6) of
2015-09-10

git hash: 8aa0386420f9d982b99568f27a5953dfc737640e

> One other thing to try is "emacsclient -t", i.e. a text-mode frame.
> Does that have the same problem, or does it display buffers as
> expected?

I played around with this and found some interesting notes.

Once the issue arises, if I execute "emacsclient -c", "emacsclient -c
filename.txt", "emacsclient -t", or "emacsclient -t filename.txt" from
a new gnome-terminal the frame opens and display correctly as
expected. It appears that only the frames created by mercurial
commands regularly have the issue, and then only sometimes.

If it helps, I execute mercurial commands from gnome-terminal and not
from within Emacs. Sometimes mercurial require an editor. My "~/.hgrc"
has the editor configured to "emacsclient -c". I'm not sure if the
fact that this issue only occurs from mercurial is significant or
merely a coincidence as other than mercurial new emacsclients are
rarely invoked.

If I execute the "emacsclient -c" from a separate terminal (as
mentioned above), then retry the mercurial command, the next frame
displays correctly as expected. It seems this sequence somehow gets
around the issue.

Thanks for the help! If there is any additional information I can
provide to help debug this issue, please let me know.

Cheers,
Jon

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Eli Zaretskii]

> Date: Fri, 11 Sep 2015 09:47:59 -0700
> From: Jon Dufresne <jon.dufresne@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> Once the issue arises, if I execute "emacsclient -c", "emacsclient -c
> filename.txt", "emacsclient -t", or "emacsclient -t filename.txt" from
> a new gnome-terminal the frame opens and display correctly as
> expected. It appears that only the frames created by mercurial
> commands regularly have the issue, and then only sometimes.

I guess the question is now what does Mercurial do, exactly, to invoke
emacsclient.  Can you look at the command line Mercurial passes to it,
for example?  Perhaps also log the communications between emacsclient
and the server on the Emacs side, and see what is passed there.

The screenshot you posted seems like the frame was never created
completely, so Emacs doesn't think it should be displaying any text
yet.  I wonder why that happens.

> If I execute the "emacsclient -c" from a separate terminal (as
> mentioned above), then retry the mercurial command, the next frame
> displays correctly as expected. It seems this sequence somehow gets
> around the issue.

We need to figure out what kind of "issue" this works around.

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Jon Dufresne]

On Mon, Sep 14, 2015 at 3:09 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Once the issue arises, if I execute "emacsclient -c", "emacsclient -c
>> filename.txt", "emacsclient -t", or "emacsclient -t filename.txt" from
>> a new gnome-terminal the frame opens and display correctly as
>> expected. It appears that only the frames created by mercurial
>> commands regularly have the issue, and then only sometimes.
>
> I guess the question is now what does Mercurial do, exactly, to invoke
> emacsclient.  Can you look at the command line Mercurial passes to it,
> for example?  Perhaps also log the communications between emacsclient
> and the server on the Emacs side, and see what is passed there.
>
> The screenshot you posted seems like the frame was never created
> completely, so Emacs doesn't think it should be displaying any text
> yet.  I wonder why that happens.
>
>> If I execute the "emacsclient -c" from a separate terminal (as
>> mentioned above), then retry the mercurial command, the next frame
>> displays correctly as expected. It seems this sequence somehow gets
>> around the issue.
>
> We need to figure out what kind of "issue" this works around.

I'm at a loss on how to continue diagnosing this issue. I continue to
hit the problem, even with the newer Emacs. Luckily less frequently
than before and it is now easier to resume normal usage, but enough
that it interrupts my flow. Any thoughts on how to possibly gather
more useful information?

Thanks,
Jon

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Eli Zaretskii]

> Date: Tue, 22 Sep 2015 17:51:45 -0700
> From: Jon Dufresne <jon.dufresne@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> > I guess the question is now what does Mercurial do, exactly, to invoke
> > emacsclient.  Can you look at the command line Mercurial passes to it,
> > for example?  Perhaps also log the communications between emacsclient
> > and the server on the Emacs side, and see what is passed there.
> >
> > The screenshot you posted seems like the frame was never created
> > completely, so Emacs doesn't think it should be displaying any text
> > yet.  I wonder why that happens.
> >
> >> If I execute the "emacsclient -c" from a separate terminal (as
> >> mentioned above), then retry the mercurial command, the next frame
> >> displays correctly as expected. It seems this sequence somehow gets
> >> around the issue.
> >
> > We need to figure out what kind of "issue" this works around.
> 
> I'm at a loss on how to continue diagnosing this issue. I continue to
> hit the problem, even with the newer Emacs. Luckily less frequently
> than before and it is now easier to resume normal usage, but enough
> that it interrupts my flow. Any thoughts on how to possibly gather
> more useful information?

I proposed above to look for 2 pieces of information that could
potentially help us.  If you can show them, I think it would be good
progress.  If you need help with them (i.e. don't know how to get the
information), please tell.

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Mike Kupfer]

Eli Zaretskii wrote:

> > > I guess the question is now what does Mercurial do, exactly, to invoke
> > > emacsclient.  Can you look at the command line Mercurial passes to it,
> > > for example?  Perhaps also log the communications between emacsclient
> > > and the server on the Emacs side, and see what is passed there.

I occasionally run into the same or a very similar issue as Jon and
Tassilo.  It's not reproducible on demand and doesn't happen often, so
I've been ignoring it.  (My usual workaround is to minimize the useless
frame and rerun emacsclient.  Like Tassilo, I run (server-start) at
startup, rather than running Emacs as a daemon.)

If it happens again, I can certainly tell you how emacsclient got
invoked.  But I could use a clue about how to log communication between
emacsclient and the server.

thanks,
mike

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Eli Zaretskii]

> From: Mike Kupfer <m.kupfer@acm.org>
> cc: Jon Dufresne <jon.dufresne@gmail.com>, emacs-devel@gnu.org
> Date: Sun, 27 Sep 2015 15:21:52 -0700
> 
> If it happens again, I can certainly tell you how emacsclient got
> invoked.  But I could use a clue about how to log communication between
> emacsclient and the server.

Set the variable server-log to a non-nil value (in your .emacs), then
look at the contents of the buffer named " *server*" after each
invocation of emacsclient.

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Mike Kupfer]

[-- Attachment #1: Type: text/plain, Size: 2583 bytes --]

After several months of not seeing this problem (last discussed in
September), I hit it today after invoking "emacsclient -c".  I've
attached a partial screenshot.  The background color looks right, and I
see the region for the menubar, but the gutters, scrollbar, and modeline
are all totally missing.

Here's the relevant excerpt from the server log for two emacsclient
invocations.  The first one is for the bad frame, the second one is for
a working frame.  I can provide the entire server log if desired.

Mon Feb 15 10:47:31 2016 server <10>: Status changed to open: open from -
Mon Feb 15 10:47:31 2016 server <10>: server-delete-client
Mon Feb 15 10:47:31 2016 server <10>: Received -env _=[...]
Mon Feb 15 10:47:31 2016 server <10>: Sent -emacs-pid 1622
Mon Feb 15 10:47:31 2016 server <10>: #<frame emacs@athyra 0x4343058> created
Mon Feb 15 10:50:52 2016 server <11>: Status changed to open: open from -
Mon Feb 15 10:50:52 2016 server <11>: server-delete-client
Mon Feb 15 10:50:52 2016 server <11>: Received -env _=[...]
Mon Feb 15 10:50:52 2016 server <11>: Sent -emacs-pid 1622
Mon Feb 15 10:50:52 2016 server <11>: #<frame emacs@athyra 0x4eba368> created

(The environment has some values that I'd rather not post on a public
list, so I've elided the environment from the above excerpt.  The only
environment difference between the 2 frames was some sort of tag that
dmenu creates, e.g.,
DESKTOP_STARTUP_ID=i3/dmenu_run/5146-9-athyra_TIME3863103774.)

Some things that I noticed that looked interesting:

1. #<frame emacs@athyra 0x4343058> (the bad frame) refers to an address
that matches a frame that was closed back on Friday.

Fri Feb 12 15:58:27 2016 server <3>: server-handle-delete-frame, frame #<frame Todo.krb5-issues 0x4343058>
Fri Feb 12 15:58:27 2016 server <3>: server-delete-client noframe
Fri Feb 12 15:58:27 2016 server <3>: Status changed to closed: deleted
Fri Feb 12 15:58:27 2016 server <3>: server-delete-client
Fri Feb 12 15:58:27 2016 server <3>: Deleted

2. The bad frame does not appear in the results from frame-list:

  (frame-list)
  (#<frame emacs@athyra 0x4eba368> #<frame journal-2016.org 0x3073760> #<frame *GNU Emacs* 0x1128268>)

3. Doing an strace of Emacs showed zero activity when I moved the mouse
over the bad frame or when I clicked in it.

Also, I'll note that gdb shows the emacsclient process trying to read
from the socket.  AFAICT there is nothing unusual there.

This was with Emacs 24.5.  I plan to install 25.0.91 on the affected
system tomorrow, but who knows how long it will take for the problem to
reproduce.

mike

[-- Attachment #2: top of bad frame --]
[-- Type: image/png, Size: 15024 bytes --]

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Eli Zaretskii]

> From: Mike Kupfer <m.kupfer@acm.org>
> Date: Mon, 15 Feb 2016 17:07:03 -0800
> 
> After several months of not seeing this problem (last discussed in
> September), I hit it today after invoking "emacsclient -c".  I've
> attached a partial screenshot.  The background color looks right, and I
> see the region for the menubar, but the gutters, scrollbar, and modeline
> are all totally missing.

According to what you found, Emacs doesn't think this frame exists.
So it's small wonder its display is severely corrupted.

> Here's the relevant excerpt from the server log for two emacsclient
> invocations.  The first one is for the bad frame, the second one is for
> a working frame.  I can provide the entire server log if desired.

I'm not sure the server log is the place to look for the problem.  Why
did you think it was relevant?

> (The environment has some values that I'd rather not post on a public
> list, so I've elided the environment from the above excerpt.  The only
> environment difference between the 2 frames was some sort of tag that
> dmenu creates, e.g.,
> DESKTOP_STARTUP_ID=i3/dmenu_run/5146-9-athyra_TIME3863103774.)

What is "dmenu"?

What kind of build is this?  (It's probably best to submit a formal
bug report where all these details will be spelled out.)

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 370 bytes --]

I can only answer the dmenu question.

> What is "dmenu"?

The OP is using this http://tools.suckless.org/dmenu/
It's basically a completion command line utility like ido-vertical/ivy.

dmenu_run (shipped with dmenu) is a special case of dmenu that suggests all
executables available in the env var $PATH and narrows down the completion
as the user types in characters.

[-- Attachment #2: Type: text/html, Size: 787 bytes --]

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Tue, 16 Feb 2016 11:38:11 -0500
> Cc: Mike Kupfer <m.kupfer@acm.org>, Emacs developers <emacs-devel@gnu.org>
> 
> > What is "dmenu"?
> 
> The OP is using this http://tools.suckless.org/dmenu/
> It's basically a completion command line utility like ido-vertical/ivy.
> 
> dmenu_run (shipped with dmenu) is a special case of dmenu that suggests all executables available in the
> env var $PATH and narrows down the completion as the user types in characters.

Thanks.  Do you see how dmenu could be relevant to the issue at hand?

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]

I don't have any knowledge in this area to provide any useful info.

One difference is that I have dmenu installed as a separate standalone
package, but my windows manager is whatever default comes with RHEL
6.6/Gnome.

But it looks like the OP has installed the i3 WM (dmenu is shipped along as
a part of i3). So the problem could be at a lower level than dmenu.

[-- Attachment #2: Type: text/html, Size: 549 bytes --]

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Mike Kupfer]

Eli Zaretskii wrote:

> > From: Mike Kupfer <m.kupfer@acm.org>
> > Here's the relevant excerpt from the server log for two emacsclient
> > invocations.  The first one is for the bad frame, the second one is for
> > a working frame.  I can provide the entire server log if desired.
> 
> I'm not sure the server log is the place to look for the problem.  Why
> did you think it was relevant?

Well, back in September when this was discussed, one of the suggestions
for the OP was to look into the "communications between emacsclient
and the server on the Emacs side, and see what is passed there."  When I
asked how to do this, I was pointed at the server log.

And the results do seem relevant.  I ran "emacsclient -c" twice within a
short period of time, and the server log showed 2 frames being created.
So *some* code in Emacs thought the first frame was created, even though
it didn't show up in the output from (frame-list).

And I still think it's suspicious that the bad frame seems to match a
frame that was deleted earlier.

> What kind of build is this?  (It's probably best to submit a formal
> bug report where all these details will be spelled out.)

It's a pretty vanilla build of 24.5 on Debian stable.

I'll go ahead and open a bug.

thanks,
mike

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Eli Zaretskii]

> From: Mike Kupfer <m.kupfer@acm.org>
> cc: emacs-devel@gnu.org
> Date: Tue, 16 Feb 2016 18:05:52 -0800
> 
> I ran "emacsclient -c" twice within a short period of time, and the
> server log showed 2 frames being created.  So *some* code in Emacs
> thought the first frame was created, even though it didn't show up
> in the output from (frame-list).

This means Emacs started creating the frame, but didn't finish that
process.  A new frame is recorded in the frame list only when it is
completely set up.  The question is: what happens during that process
which prevents it from completing?

At this point, it looks like instrumenting x-create-frame to write
traces to some file might tell what causes that function to stop doing
its job half way through.

> And I still think it's suspicious that the bad frame seems to match a
> frame that was deleted earlier.

Was the deleted frame deleted from the frame list?

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Mike Kupfer]

As suggested, I've opened a bug for this: #22728.

Eli Zaretskii wrote:

> > From: Mike Kupfer <m.kupfer@acm.org>
> > cc: emacs-devel@gnu.org
> > Date: Tue, 16 Feb 2016 18:05:52 -0800
> > 
> > I ran "emacsclient -c" twice within a short period of time, and the
> > server log showed 2 frames being created.  So *some* code in Emacs
> > thought the first frame was created, even though it didn't show up
> > in the output from (frame-list).
> 
> This means Emacs started creating the frame, but didn't finish that
> process.  A new frame is recorded in the frame list only when it is
> completely set up.  The question is: what happens during that process
> which prevents it from completing?
> 
> At this point, it looks like instrumenting x-create-frame to write
> traces to some file might tell what causes that function to stop doing
> its job half way through.

Okay.  If someone provides a patch, I'd be happy to apply it on the
systems I run Emacs on.  I can also look at instrumenting
x-create-frame myself.  That will take longer to set up, but given how
long it is between occurrences of this problem, some initial delay
probably doesn't matter much.

I wonder if the problem is particular to a certain widget set.  If
anyone has suggestions for instrumenting the Athena (2D) widget set, I'd
welcome them.

> > And I still think it's suspicious that the bad frame seems to match a
> > frame that was deleted earlier.
> 
> Was the deleted frame deleted from the frame list?

I'm not sure I understand the question.  The frame list that I looked at
on the 15th had these 3 frames:

  (#<frame emacs@athyra 0x4eba368>
   #<frame journal-2016.org 0x3073760>
   #<frame *GNU Emacs* 0x1128268>)

(This was after the bad frame was created.)

The log showed the deletion of

  #<frame Todo.krb5-issues 0x4343058>

on the 12th, and the creation of

  #<frame emacs@athyra 0x4343058>

on the 15th.  Let me know if that doesn't answer your question.

thanks and regards,
mike

Re: Need help debugging Emacs: emacsclient will not draw its contents sometimes

[Eli Zaretskii]

> From: Mike Kupfer <m.kupfer@acm.org>
> cc: emacs-devel@gnu.org
> Date: Wed, 17 Feb 2016 21:01:15 -0800
> 
> > At this point, it looks like instrumenting x-create-frame to write
> > traces to some file might tell what causes that function to stop doing
> > its job half way through.
> 
> Okay.  If someone provides a patch, I'd be happy to apply it on the
> systems I run Emacs on.  I can also look at instrumenting
> x-create-frame myself.  That will take longer to set up, but given how
> long it is between occurrences of this problem, some initial delay
> probably doesn't matter much.

Let me know if you need help in this matter.  I can suggest some code,
but I cannot easily test it.

What I had in mind is adding code to x-create-frame, which would:

  . open a file with a certain fixed file name, in append mode
  . write series of trace info records to the file
  . close the file

For the 2nd bullet above, inject 'fprintf' lines into x-create-frame
at strategic places which record the frame name and address.  The
strategic places I'd consider are calls to other functions, especially
those that are X and toolkit calls.  Examples upon the first glance
are: initialize_frame_menubar, x_wm_set_size_hint, adjust_frame_size,
XChangeProperty, and the loop with calls fset_param_alist.  The
purpose of this is to find out which of these calls returns
successfully, and which doesn't.  Once we know which call doesn't
return, we can look into that call to find out what happens there and
why.

> > > And I still think it's suspicious that the bad frame seems to match a
> > > frame that was deleted earlier.
> > 
> > Was the deleted frame deleted from the frame list?
> 
> I'm not sure I understand the question.  The frame list that I looked at
> on the 15th had these 3 frames:
> 
>   (#<frame emacs@athyra 0x4eba368>
>    #<frame journal-2016.org 0x3073760>
>    #<frame *GNU Emacs* 0x1128268>)
> 
> (This was after the bad frame was created.)
> 
> The log showed the deletion of
> 
>   #<frame Todo.krb5-issues 0x4343058>
> 
> on the 12th, and the creation of
> 
>   #<frame emacs@athyra 0x4343058>
> 
> on the 15th.  Let me know if that doesn't answer your question.

So you are saying that a new frame as created using the same address
as used by a frame that was previously deleted.  I don't think this
means trouble, it just means Emacs reused the same memory for a new
frame object.