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: Mon, 09 Oct 2017 13:36:41 -0600
> 
> Thread 1 "emacs" hit Hardware watchpoint 4: -location $2->redisplay
> 
> Old value = false
> New value = true
> fset_redisplay (f=0x15cac30 <bss_sbrk_buffer+8062480>) at xdisp.c:600
> 600	}
> #0  0x000000000043eddc in fset_redisplay (f=0x15cac30 <bss_sbrk_buffer+8062480>) at xdisp.c:600
> #1  0x000000000057abb6 in xg_update_scrollbar_pos (f=0x15cac30 <bss_sbrk_buffer+8062480>, scrollbar_id=0, top=0, left=736, width=16, height=612) at gtkutil.c:3942
> #2  0x0000000000547fd9 in XTset_vertical_scroll_bar (w=0x15cbc30 <bss_sbrk_buffer+8066576>, portion=1228, whole=8237, position=0) at xterm.c:6809
> #3  0x00000000004728d9 in set_vertical_scroll_bar (w=0x15cbc30 <bss_sbrk_buffer+8066576>) at xdisp.c:16372
> #4  0x0000000000476f90 in redisplay_window (window=XIL(0x15cbc35), just_this_one_p=false) at xdisp.c:17527

Thanks, this is what I suspected: the difference between our systems
is that your Emacs is built with GTK, and moving the thumb of the GTK
scroll bar marks the frame garbaged, which also sets its redisplay
flag.

So this mystery is now solved, and we can close the bug.