[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#28710: 27.0.50; eassert failure in maybe_produce_line_number
From: |
Eli Zaretskii |
Subject: |
bug#28710: 27.0.50; eassert failure in maybe_produce_line_number |
Date: |
Mon, 09 Oct 2017 15:40:40 +0300 |
> From: Alex <agrambot@gmail.com>
> Cc: 28710@debbugs.gnu.org
> Date: Sun, 08 Oct 2017 15:19:53 -0600
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > OK, so we need to understand the path the code takes after try_window
> > returns the value 1. This means, after typing "finish" 3 times, type
> > "next", then continue pressing RET until redisplay_window returns. I
> > need to see the path through the code until we exit redisplay_window
> > to understand where to put the missing call to clear_glyph_matrix.
>
> Thread 1 "emacs" hit Hardware watchpoint 2: -location
> $1->desired_matrix->rows->enabled_p
Thanks. I installed a change that should fix the problem, please try
the latest emacs-26 branch.
As to why this doesn't happen to me: for some reason, on your system,
when all the frame's windows have been redisplayed, their frame's
'redisplay' flag is set, and that causes redisplay_internal to
immediately redisplay all the windows again, see this part of your
transcript:
> 14320 if (!f_redisplay_flag && f->redisplay)
> (gdb)
> 14321 goto retry_frame;
On my system, the 'redisplay' flag stays reset, so this goto is
bypassed, and the problem doesn't happen. If you can afford one last
effort, please re-run the recipe with a watchpoint set on the frame's
'redisplay' flag, and show the backtraces from every one of the
watchpoint's hits, then perhaps I will know next time what else to try
to reproduce such cases.
Specifically, after invoking redraw-display, which causes GDB to kick
in, do this:
Thread 1 hit Breakpoint 3, Fredraw_display () at dispnew.c:3032
3032 FOR_EACH_FRAME (tail, frame)
(gdb) n
3033 if (FRAME_VISIBLE_P (XFRAME (frame)))
(gdb) p XFRAME(frame)
$1 = (struct frame *) 0x1b5e380 <dumped_data+4020672>
(gdb) p $1->redisplay
$2 = true
(gdb) watch -l $1->redisplay
Hardware watchpoint 4: -location $1->redisplay
(gdb) commands
> bt
> continue
> end
(gdb) continue
and then continue with the recipe, and show all the backtraces you get.
- bug#28710: 27.0.50; eassert failure in maybe_produce_line_number, (continued)
- bug#28710: 27.0.50; eassert failure in maybe_produce_line_number, Eli Zaretskii, 2017/10/06
- bug#28710: 27.0.50; eassert failure in maybe_produce_line_number, Alex, 2017/10/07
- bug#28710: 27.0.50; eassert failure in maybe_produce_line_number, Eli Zaretskii, 2017/10/08
- bug#28710: 27.0.50; eassert failure in maybe_produce_line_number, Alex, 2017/10/08
- bug#28710: 27.0.50; eassert failure in maybe_produce_line_number, Eli Zaretskii, 2017/10/08
- bug#28710: 27.0.50; eassert failure in maybe_produce_line_number, Eli Zaretskii, 2017/10/08
- bug#28710: 27.0.50; eassert failure in maybe_produce_line_number, Eli Zaretskii, 2017/10/09
- bug#28710: 27.0.50; eassert failure in maybe_produce_line_number, Alex, 2017/10/08
- bug#28710: 27.0.50; eassert failure in maybe_produce_line_number, Eli Zaretskii, 2017/10/08
- bug#28710: 27.0.50; eassert failure in maybe_produce_line_number, Alex, 2017/10/08
- bug#28710: 27.0.50; eassert failure in maybe_produce_line_number,
Eli Zaretskii <=
- bug#28710: 27.0.50; eassert failure in maybe_produce_line_number, Alex, 2017/10/09
- bug#28710: 27.0.50; eassert failure in maybe_produce_line_number, Eli Zaretskii, 2017/10/09
- bug#28710: 27.0.50; eassert failure in maybe_produce_line_number, Alex, 2017/10/09
- bug#28710: 27.0.50; eassert failure in maybe_produce_line_number, Eli Zaretskii, 2017/10/10