bug#28710: 27.0.50; eassert failure in maybe_produce_line_number

[Eli Zaretskii <eliz@gnu.org>]

> From: Alex <agrambot@gmail.com>
> Cc: 28710@debbugs.gnu.org
> Date: Sun, 08 Oct 2017 01:11:37 -0600
> 
> Sorry, it seems that "M-x gdb" doesn't show the output of the commands
> for me (is that a bug?)

Maybe it's a bug, I will look into that later.

> I had to try gdb on the command line to get the following:
[...]
> Thread 1 "emacs" hit Hardware watchpoint 4: -location $1->desired_matrix->rows->enabled_p
> 
> Old value = false
> New value = true
> prepare_desired_row (w=0x15cac30 <bss_sbrk_buffer+8062480>, row=0x3a48c60, mode_line_p=false) at dispnew.c:1076
> 1076	      row->reversed_p = rp;
> #0  0x000000000041c601 in prepare_desired_row (w=0x15cac30 <bss_sbrk_buffer+8062480>, row=0x3a48c60, mode_line_p=false) at dispnew.c:1076
> #1  0x0000000000484290 in display_line (it=0x7ffcdcb79f50, cursor_vpos=15) at xdisp.c:21206
> #2  0x0000000000477380 in try_window (window=XIL(0x15cac35), pos=..., flags=1) at xdisp.c:17592
> #3  0x0000000000474866 in redisplay_window (window=XIL(0x15cac35), just_this_one_p=false) at xdisp.c:17039

Hmm... now I'm confused.  Your original backtrace with assertion
violation indicated that it happened with the same call-stack below
redisplay_window:

> #1  0x000000000058c5d5 in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:394
> #2  0x00000000006233ad in die (msg=0x72ad60 "it->glyph_row == NULL || it->glyph_row->used[TEXT_AREA] == 0", file=0x726c3d "xdisp.c", line=21061) at alloc.c:7419
> #3  0x0000000000483af6 in maybe_produce_line_number (it=0x7ffef1f01900) at xdisp.c:21061
> #4  0x00000000004844c0 in display_line (it=0x7ffef1f01900, cursor_vpos=9) at xdisp.c:21276
> #5  0x00000000004772b8 in try_window (window=..., pos=..., flags=1) at xdisp.c:17592
> #6  0x000000000047479e in redisplay_window (window=..., just_this_one_p=false) at xdisp.c:17039

The only difference is the value of cursor_vpos (probably because you
hit RET on a different line or generally used a different commit?).
But if prepare_desired_row _does_ reset the enabled_p flag, then the
assertion violation could not have happened...

Perhaps try_window is called again, after the call which hit the
watchpoint?  To see if that's the case, please run the session again,
but modify it as follows:

  . do NOT define commands for the watchpoint
  . when the watchpoint triggers the first 2 times, type "continue"
  . when it triggers for the 3rd time, type these commands:

   (gdb) break xdisp.c:17039
   (gdb) commands
         > p w->desired_matrix->rows->enabled_p
	 > end
   (gdb) finish
   (gdb) finish
   (gdb) finish
   (gdb) continue

Then please tell: (a) what was the return value of try_window, as
printed in response to the 3rd "finish" command, and (b) whether the
breakpoint set on line 17039 of xdisp.c triggers right after that.  If
the breakpoint does trigger, please see if the value of the enabled_p
flag is printed as true or false.

> Too bad you still can't reproduce it; every build I've configured
> with "--enable-checking=yes,glyphs --enable-check-lisp-object-type
> 'CFLAGS=-O0 -g3'" crashes here.

I agree that it's unfortunate.  If you prefer, we could instead try
investigating why it doesn't happen for me: maybe we will succeed in
finding a variation that does, and then I can debug it here.

Here are some reasons why my configuration could work differently:

  . the default font/font size is different (although I did try 3
    non-default font sizes as well)
  . my Magit is not installed and is not byte-compiled, and neither
    are its dependencies, dash.el and with-editor.el; instead, I load
    Magit manually, using load-library, from the directory where I
    downloaded the latest Magit snapshot, before typing the recipe
    commands

Thanks.