bug#28710: 27.0.50; eassert failure in maybe_produce_line_number

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#28710: 27.0.50; eassert failure in maybe_produce_line_number

Alex-2

I can so far only produce this with magit[1], but I've attached the output
of "bt full" below.

1. Open up a diff in magit (e.g., M-x magit-status then RET on the first
line).
2. Press RET on an added line.
3. In the opened buffer, do M-: (setq display-line-numbers t)
4. C-x b RET
5. Press RET on the line again.

If I use (e)debug to try and trace the function call, then for whatever
reason it doesn't crash at step 5, but a call to `list-buffers' will
then crash. It also doesn't crash if I use (call-interactively
#'magit-diff-visit-file) rather than hitting RET, even though RET is
bound to `magit-diff-visit-file'.

Footnotes:

[1] https://github.com/magit/magit



In GNU Emacs 27.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.22.21)
 of 2017-10-04 built on lylat
Repository revision: 92045f4546b9708dc9f69954799d211c1f56ff1e
Windowing system distributor 'The X.Org Foundation', version 11.0.11903000
System Description: Debian GNU/Linux testing (buster)

Configured using:
 'configure --enable-checking=yes,glyphs --enable-check-lisp-object-type
 'CFLAGS=-O0 -g3''

backtrace-orig (84K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#28710: 27.0.50; eassert failure in maybe_produce_line_number

Eli Zaretskii
> From: Alex <[hidden email]>
> Date: Wed, 04 Oct 2017 16:31:33 -0600
>
> 1. Open up a diff in magit (e.g., M-x magit-status then RET on the first
> line).
> 2. Press RET on an added line.
> 3. In the opened buffer, do M-: (setq display-line-numbers t)
> 4. C-x b RET
> 5. Press RET on the line again.

It doesn't crash for me here.  But since it's hardly repeatable for
you, I'm not surprised.

> #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

If you go to frame #3, in maybe_produce_line_number, and type

  (gdb) pgrowx it->glyph_row

what does that produce?  (You will need to source src/.gdbinit for the
pgrowx command to work.)

Btw, your recipe didn't quite work for me: the first step failed when
I pressed RET "on the first line" of the buffer presented by "M-x
magit-status" in the current release branch tip.  It said there was
nothing to show about that line.  I needed to find a suitable line
further down in the buffer.  Am I missing something here?  Can you
specify precise steps, assuming I know nothing about using Magit?

Thanks.



Reply | Threaded
Open this post in threaded view
|

bug#28710: 27.0.50; eassert failure in maybe_produce_line_number

Alex-2
Eli Zaretskii <[hidden email]> writes:

>> From: Alex <[hidden email]>
>> Date: Wed, 04 Oct 2017 16:31:33 -0600
>>
>> 1. Open up a diff in magit (e.g., M-x magit-status then RET on the first
>> line).
>> 2. Press RET on an added line.
>> 3. In the opened buffer, do M-: (setq display-line-numbers t)
>> 4. C-x b RET
>> 5. Press RET on the line again.
>
> It doesn't crash for me here.  But since it's hardly repeatable for
> you, I'm not surprised.

What about using the below recipe?

>> #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
>
> If you go to frame #3, in maybe_produce_line_number, and type
>
>   (gdb) pgrowx it->glyph_row
>
> what does that produce?  (You will need to source src/.gdbinit for the
> pgrowx command to work.)

TEXT: 34 glyphs
  0    0: CHAR[ ] pos=-1 blev=2,btyp=EN w=9 a+d=14+4 face=35 MB AVOID
  1    9: CHAR[3] pos=-1 blev=2,btyp=EN w=9 a+d=14+4 face=35 MB AVOID
  2   18: CHAR[1] pos=-1 blev=2,btyp=EN w=9 a+d=14+4 face=35 MB AVOID
  3   27: CHAR[3] pos=-1 blev=2,btyp=EN w=9 a+d=14+4 face=35 MB AVOID
  4   36: CHAR[0] pos=-1 blev=2,btyp=EN w=9 a+d=14+4 face=35 MB AVOID
  5   45: CHAR[ ] pos=-1 blev=2,btyp=EN w=9 a+d=14+4 face=35 MB AVOID
  6   54: CHAR[@] pos=123808 blev=0,btyp=L w=9 a+d=14+4 MB
  7   63: CHAR[c] pos=123809 blev=0,btyp=L w=9 a+d=14+4 face=30 MB
  8   72: CHAR[o] pos=123810 blev=0,btyp=L w=9 a+d=14+4 face=30 MB
  9   81: CHAR[d] pos=123811 blev=0,btyp=L w=9 a+d=14+4 face=30 MB
 10   90: CHAR[e] pos=123812 blev=0,btyp=L w=9 a+d=14+4 face=30 MB
 11   99: CHAR[{] pos=123813 blev=0,btyp=L w=9 a+d=14+4 MB
 12  108: CHAR[f] pos=123814 blev=0,btyp=L w=9 a+d=14+4 face=33 MB
 13  117: CHAR[i] pos=123815 blev=0,btyp=L w=9 a+d=14+4 face=33 MB
 14  126: CHAR[l] pos=123816 blev=0,btyp=L w=9 a+d=14+4 face=33 MB
 15  135: CHAR[e] pos=123817 blev=0,btyp=L w=9 a+d=14+4 face=33 MB
 16  144: CHAR[-] pos=123818 blev=0,btyp=L w=9 a+d=14+4 face=33 MB
 17  153: CHAR[n] pos=123819 blev=0,btyp=L w=9 a+d=14+4 face=33 MB
 18  162: CHAR[a] pos=123820 blev=0,btyp=L w=9 a+d=14+4 face=33 MB
 19  171: CHAR[m] pos=123821 blev=0,btyp=L w=9 a+d=14+4 face=33 MB
 20  180: CHAR[e] pos=123822 blev=0,btyp=L w=9 a+d=14+4 face=33 MB
 21  189: CHAR[-] pos=123823 blev=0,btyp=L w=9 a+d=14+4 face=33 MB
 22  198: CHAR[d] pos=123824 blev=0,btyp=L w=9 a+d=14+4 face=33 MB
 23  207: CHAR[i] pos=123825 blev=0,btyp=L w=9 a+d=14+4 face=33 MB
 24  216: CHAR[r] pos=123826 blev=0,btyp=L w=9 a+d=14+4 face=33 MB
 25  225: CHAR[e] pos=123827 blev=0,btyp=L w=9 a+d=14+4 face=33 MB
 26  234: CHAR[c] pos=123828 blev=0,btyp=L w=9 a+d=14+4 face=33 MB
 27  243: CHAR[t] pos=123829 blev=0,btyp=L w=9 a+d=14+4 face=33 MB
 28  252: CHAR[o] pos=123830 blev=0,btyp=L w=9 a+d=14+4 face=33 MB
 29  261: CHAR[r] pos=123831 blev=0,btyp=L w=9 a+d=14+4 face=33 MB
 30  270: CHAR[y] pos=123832 blev=0,btyp=L w=9 a+d=14+4 face=33 MB
 31  279: CHAR[}] pos=123833 blev=0,btyp=L w=9 a+d=14+4 MB
 32  288: CHAR[,] pos=123834 blev=0,btyp=L w=9 a+d=14+4 MB
 33  297: CHAR[ ] pos=0 blev=0,btyp=B w=9 a+d=14+4 MB
 
> Btw, your recipe didn't quite work for me: the first step failed when
> I pressed RET "on the first line" of the buffer presented by "M-x
> magit-status" in the current release branch tip.  It said there was
> nothing to show about that line.  I needed to find a suitable line
> further down in the buffer.  Am I missing something here?  Can you
> specify precise steps, assuming I know nothing about using Magit?

That's odd, since I believe unless there was a git error the first line
should start with "Head:" and pressing RET on it shows the commit at
HEAD. Maybe there's another situation where that's not the case.

Anyway, this might be more consistent:

1. emacs -Q in a directory containing a git repository
2. M-x package-initialize if needed
2. M-x magit-show-commit RET RET (should default to master)
This should bring up a *magit-revision buffer.
3. Move point to an added line (or any line in a hunk, under the @@
lines) and press RET
4. M-: (setq display-line-numbers t)
5. C-x b RET (should take you back to the *magit-revision buffer)
6. RET

Just to specify a commit, try M-x magit-show-commit RET 92045f45 RET in
an Emacs repo and press RET on the following line:
+@code{file-symlink-p}, @code{file-system-info}



Reply | Threaded
Open this post in threaded view
|

bug#28710: 27.0.50; eassert failure in maybe_produce_line_number

Eli Zaretskii
merge 28710 27668
thanks

> From: Alex <[hidden email]>
> Cc: [hidden email]
> Date: Thu, 05 Oct 2017 17:51:41 -0600
>
> > It doesn't crash for me here.  But since it's hardly repeatable for
> > you, I'm not surprised.
>
> What about using the below recipe?

Thanks, but still no cigar.

> > If you go to frame #3, in maybe_produce_line_number, and type
> >
> >   (gdb) pgrowx it->glyph_row
> >
> > what does that produce?  (You will need to source src/.gdbinit for the
> > pgrowx command to work.)
>
> TEXT: 34 glyphs
>   0    0: CHAR[ ] pos=-1 blev=2,btyp=EN w=9 a+d=14+4 face=35 MB AVOID
>   1    9: CHAR[3] pos=-1 blev=2,btyp=EN w=9 a+d=14+4 face=35 MB AVOID
>   2   18: CHAR[1] pos=-1 blev=2,btyp=EN w=9 a+d=14+4 face=35 MB AVOID
>   3   27: CHAR[3] pos=-1 blev=2,btyp=EN w=9 a+d=14+4 face=35 MB AVOID
>   4   36: CHAR[0] pos=-1 blev=2,btyp=EN w=9 a+d=14+4 face=35 MB AVOID
>   5   45: CHAR[ ] pos=-1 blev=2,btyp=EN w=9 a+d=14+4 face=35 MB AVOID
>   6   54: CHAR[@] pos=123808 blev=0,btyp=L w=9 a+d=14+4 MB

It sounds like you've rediscovered bug#27668.  Robert Pluim lost the
ability to reproduce it when we were close to catching the offending
code, but maybe you will be able to pick up where he left off?  In a
nutshell, the glyph rows where display_line produces glyphs are not
cleared, so they still hold the glyphs produced by some previous code
in the display engine.  The question is where should we add a call to
clear_glyph_matrix to force the glyph rows to be cleared at the
beginning of display_line.

I wrote instructions for a debugging session to find that out, see

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27668#89

Instead of "r -Q", type just "run" to run Emacs as usual, or even
attach to an already running Emacs with "gdb -p", set the breakpoint,
and type "continue.  The "Inside Emacs" part will have to be replaced
with your recipe, up to and including step 5, and you should invoke
redraw-display just before hitting the final RET in step 6, the one
that triggers the assertion.  After performing the GDB commands and
continuing Emacs, hit RET, and post the backtraces from every time the
watchpoint set by those GDB commands is hit.  I hope we will then see
the offending code that needs to be fixed.

Let me know if you need me to rewrite the instructions to fit your
case exactly.

> > Btw, your recipe didn't quite work for me: the first step failed when
> > I pressed RET "on the first line" of the buffer presented by "M-x
> > magit-status" in the current release branch tip.  It said there was
> > nothing to show about that line.  I needed to find a suitable line
> > further down in the buffer.  Am I missing something here?  Can you
> > specify precise steps, assuming I know nothing about using Magit?
>
> That's odd, since I believe unless there was a git error the first line
> should start with "Head:" and pressing RET on it shows the commit at
> HEAD. Maybe there's another situation where that's not the case.

What if HEAD is a merge-commit?  I think this is what I got when I
tried.  Anyway, this is just a tangential issue.

> Just to specify a commit, try M-x magit-show-commit RET 92045f45 RET in
> an Emacs repo and press RET on the following line:
> +@code{file-symlink-p}, @code{file-system-info}

You mean "C-u M-x magit-show-commit", right?  Tried this as well,
still no assertion violation.

Thanks.

P.S. Btw, I'm debugging this in the emacs-26 branch, so perhaps so
should you, to avoid any irrelevant differences between what you and I
see.  I tried reproducing the assertion violation in both branches,
and failed in both.



Reply | Threaded
Open this post in threaded view
|

bug#28710: 27.0.50; eassert failure in maybe_produce_line_number

Alex-2
Eli Zaretskii <[hidden email]> writes:

> I wrote instructions for a debugging session to find that out, see
>
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27668#89
>
> Instead of "r -Q", type just "run" to run Emacs as usual, or even
> attach to an already running Emacs with "gdb -p", set the breakpoint,
> and type "continue.  The "Inside Emacs" part will have to be replaced
> with your recipe, up to and including step 5, and you should invoke
> redraw-display just before hitting the final RET in step 6, the one
> that triggers the assertion.  After performing the GDB commands and
> continuing Emacs, hit RET, and post the backtraces from every time the
> watchpoint set by those GDB commands is hit.  I hope we will then see
> the offending code that needs to be fixed.
>
> Let me know if you need me to rewrite the instructions to fit your
> case exactly.

Okay, I've pasted the output below. 2 watchpoints triggered right after
M-x redraw-display, and I only get the third before the assertion.

After your recipe, you mention update_display and how it runs after
Emacs "redrawn the window to the glass", so it should be noted that the
assertion violated is triggered before the buffer with
display-line-numbers is displayed.

Thread 1 "emacs" hit Hardware watchpoint 4: -location $1->desired_matrix->rows->enabled_p

Old value = false
New value = true
prepare_desired_row (w=0x45066d0, row=0x4509fa0, mode_line_p=true) at dispnew.c:1076
1076      row->reversed_p = rp;
(gdb)
Lisp Backtrace:
"redisplay_internal (C function)" (0x0)

Thread 1 "emacs" hit Hardware watchpoint 4: -location $1->desired_matrix->rows->enabled_p

Old value = true
New value = false
clear_glyph_matrix_rows (matrix=0x38d2a30, start=0, end=37) at dispnew.c:693
693  for (; start < end; ++start)

Lisp Backtrace:
"redisplay_internal (C function)" (0x0)

Thread 1 "emacs" hit Hardware watchpoint 4: -location $1->desired_matrix->rows->enabled_p

Old value = false
New value = true
prepare_desired_row (w=0x45066d0, row=0x4509fa0, mode_line_p=false) at dispnew.c:1076
1076      row->reversed_p = rp;

Lisp Backtrace:
"redisplay_internal (C function)" (0x0)

Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:364
364  signal (sig, SIG_DFL);

>> That's odd, since I believe unless there was a git error the first line
>> should start with "Head:" and pressing RET on it shows the commit at
>> HEAD. Maybe there's another situation where that's not the case.
>
> What if HEAD is a merge-commit?  I think this is what I got when I
> tried.  Anyway, this is just a tangential issue.

I believe it should still show the "Head:" line, but there's no hunks
that are displayed in the revision buffer. I tried reproducing by
pressing RET on a filename in its revision buffer and it also crashes.

>> Just to specify a commit, try M-x magit-show-commit RET 92045f45 RET in
>> an Emacs repo and press RET on the following line:
>> +@code{file-symlink-p}, @code{file-system-info}
>
> You mean "C-u M-x magit-show-commit", right?  Tried this as well,
> still no assertion violation.

If you want to force a completing-read for the commit, then yes. 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.

> P.S. Btw, I'm debugging this in the emacs-26 branch, so perhaps so
> should you, to avoid any irrelevant differences between what you and I
> see.  I tried reproducing the assertion violation in both branches,
> and failed in both.

Okay, the debugging done above is with an up-to-date emacs-26
branch.



Reply | Threaded
Open this post in threaded view
|

bug#28710: 27.0.50; eassert failure in maybe_produce_line_number

Eli Zaretskii
> From: Alex <[hidden email]>
> Cc: [hidden email]
> Date: Sat, 07 Oct 2017 17:05:34 -0600
>
> > I wrote instructions for a debugging session to find that out, see
> >
> >   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27668#89
> >
> > Instead of "r -Q", type just "run" to run Emacs as usual, or even
> > attach to an already running Emacs with "gdb -p", set the breakpoint,
> > and type "continue.  The "Inside Emacs" part will have to be replaced
> > with your recipe, up to and including step 5, and you should invoke
> > redraw-display just before hitting the final RET in step 6, the one
> > that triggers the assertion.  After performing the GDB commands and
> > continuing Emacs, hit RET, and post the backtraces from every time the
> > watchpoint set by those GDB commands is hit.  I hope we will then see
> > the offending code that needs to be fixed.
> >
> > Let me know if you need me to rewrite the instructions to fit your
> > case exactly.
>
> Okay, I've pasted the output below. 2 watchpoints triggered right after
> M-x redraw-display, and I only get the third before the assertion.
>
> After your recipe, you mention update_display and how it runs after
> Emacs "redrawn the window to the glass", so it should be noted that the
> assertion violated is triggered before the buffer with
> display-line-numbers is displayed.

Thanks, but I need a backtrace at each hit of the watchpoint.  The GDB
session I posted defined commands to be executed at the watchpoint, so
such a backtrace should have been executed whenever the watchpoint
triggered.  Those backtraces is what I need to determine where is the
enabled_p flag set, because one of those places is unexpected by the
code.  It's probably the last, but given what you posted, I cannot
see where did the call to prepare_desired_row originated.

Thanks.



Reply | Threaded
Open this post in threaded view
|

bug#28710: 27.0.50; eassert failure in maybe_produce_line_number

Alex-2
Eli Zaretskii <[hidden email]> writes:

> Thanks, but I need a backtrace at each hit of the watchpoint.  The GDB
> session I posted defined commands to be executed at the watchpoint, so
> such a backtrace should have been executed whenever the watchpoint
> triggered.  Those backtraces is what I need to determine where is the
> enabled_p flag set, because one of those places is unexpected by the
> code.  It's probably the last, but given what you posted, I cannot
> see where did the call to prepare_desired_row originated.
>
> Thanks.

Sorry, it seems that "M-x gdb" doesn't show the output of the commands
for me (is that a bug?), even with "M-x gdb-many-windows". I had to try
gdb on the command line to get the following:

Old value = false
New value = true
prepare_desired_row (w=0x15cac30 <bss_sbrk_buffer+8062480>, row=0x3a48c60,
    mode_line_p=true) 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=true) at dispnew.c:1076
#1  0x000000000048c268 in display_mode_line (w=0x15cac30 <bss_sbrk_buffer+8062480>, face_id=HEADER_LINE_FACE_ID, format=XIL(0x4472854)) at xdisp.c:23210
#2  0x000000000048c151 in display_mode_lines (w=0x15cac30 <bss_sbrk_buffer+8062480>) at xdisp.c:23177
#3  0x000000000047608e in redisplay_window (window=XIL(0x15cac35), just_this_one_p=false) at xdisp.c:17416
#4  0x000000000046d001 in redisplay_window_0 (window=XIL(0x15cac35))
    at xdisp.c:14799
#5  0x0000000000646f53 in internal_condition_case_1 (bfun=0x46cfbf <redisplay_window_0>, arg=XIL(0x15cac35), handlers=XIL(0xe82d93), hfun=0x46cf87 <redisplay_window_error>) at eval.c:1356
---Type <return> to continue, or q <return> to quit---
#6  0x000000000046cf5c in redisplay_windows (window=XIL(0x15cac35)) at xdisp.c:14779
#7  0x000000000046b8f5 in redisplay_internal () at xdisp.c:14268
#8  0x00000000004690da in redisplay () at xdisp.c:13488
#9  0x0000000000594c9f in read_char (commandflag=1, map=XIL(0x4466753), prev_event=XIL(0), used_mouse_menu=0x7ffcdcb7f3bf, end_time=0x0) at keyboard.c:2480
#10 0x00000000005a4ffd in read_key_sequence (keybuf=0x7ffcdcb7f510, bufsize=30, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false)
    at keyboard.c:9147
#11 0x00000000005918d0 in command_loop_1 () at keyboard.c:1368
#12 0x0000000000646e78 in internal_condition_case (bfun=0x59148c <command_loop_1>, handlers=XIL(0x5220), hfun=0x590a93 <cmd_error>) at eval.c:1332
#13 0x0000000000591066 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1110
#14 0x0000000000646381 in internal_catch (tag=XIL(0xc6c0), func=0x591039 <command_loop_2>, arg=XIL(0)) at eval.c:1097
#15 0x0000000000591004 in command_loop () at keyboard.c:1089
#16 0x000000000059057d in recursive_edit_1 () at keyboard.c:695
#17 0x0000000000590772 in Frecursive_edit () at keyboard.c:766
#18 0x000000000058e31a in main (argc=2, argv=0x7ffcdcb7f9d8) at emacs.c:1713

Lisp Backtrace:
"redisplay_internal (C function)" (0x0)

Thread 1 "emacs" hit Hardware watchpoint 4: -location $1->desired_matrix->rows->enabled_p

Old value = true
New value = false
clear_glyph_matrix_rows (matrix=0x3778570, start=0, end=37) at dispnew.c:693
693  for (; start < end; ++start)
#0  0x000000000041b026 in clear_glyph_matrix_rows (matrix=0x3778570, start=0, end=37) at dispnew.c:693
#1  0x000000000041b060 in clear_glyph_matrix (matrix=0x3778570) at dispnew.c:712
#2  0x0000000000421a79 in update_window (w=0x15cac30 <bss_sbrk_buffer+8062480>, force_p=true) at dispnew.c:3554
#3  0x0000000000420d9c in update_window_tree (w=0x15cac30 <bss_sbrk_buffer+8062480>, force_p=true) at dispnew.c:3221
#4  0x0000000000420956 in update_frame (f=0x15c9c30 <bss_sbrk_buffer+8058384>, force_p=true, inhibit_hairy_id_p=false) at dispnew.c:3110
#5  0x000000000046bb29 in redisplay_internal () at xdisp.c:14346
#6  0x00000000004690da in redisplay () at xdisp.c:13488
#7  0x0000000000594c9f in read_char (commandflag=1, map=XIL(0x4466753), prev_event=XIL(0), used_mouse_menu=0x7ffcdcb7f3bf, end_time=0x0) at keyboard.c:2480
#8  0x00000000005a4ffd in read_key_sequence (keybuf=0x7ffcdcb7f510, bufsize=30, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false)
    at keyboard.c:9147
#9  0x00000000005918d0 in command_loop_1 () at keyboard.c:1368
#10 0x0000000000646e78 in internal_condition_case (bfun=0x59148c <command_loop_1>, handlers=XIL(0x5220), hfun=0x590a93 <cmd_error>) at eval.c:1332
#11 0x0000000000591066 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1110
#12 0x0000000000646381 in internal_catch (tag=XIL(0xc6c0), func=0x591039 <command_loop_2>, arg=XIL(0)) at eval.c:1097
#13 0x0000000000591004 in command_loop () at keyboard.c:1089
#14 0x000000000059057d in recursive_edit_1 () at keyboard.c:695
#15 0x0000000000590772 in Frecursive_edit () at keyboard.c:766
#16 0x000000000058e31a in main (argc=2, argv=0x7ffcdcb7f9d8) at emacs.c:1713

Lisp Backtrace:
"redisplay_internal (C function)" (0x0)

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
---Type <return> to continue, or q <return> to quit---
#3  0x0000000000474866 in redisplay_window (window=XIL(0x15cac35), just_this_one_p=false) at xdisp.c:17039
#4  0x000000000046d001 in redisplay_window_0 (window=XIL(0x15cac35)) at xdisp.c:14799
#5  0x0000000000646f53 in internal_condition_case_1 (bfun=0x46cfbf <redisplay_window_0>, arg=XIL(0x15cac35), handlers=XIL(0xe82d93), hfun=0x46cf87 <redisplay_window_error>) at eval.c:1356
#6  0x000000000046cf5c in redisplay_windows (window=XIL(0x15cac35)) at xdisp.c:14779
#7  0x000000000046b8f5 in redisplay_internal () at xdisp.c:14268
#8  0x000000000046c628 in redisplay_preserve_echo_area (from_where=5) at xdisp.c:14602
#9  0x0000000000594c98 in read_char (commandflag=1, map=XIL(0x448fc93), prev_event=XIL(0), used_mouse_menu=0x7ffcdcb7f3bf, end_time=0x0) at keyboard.c:2478
#10 0x00000000005a4ffd in read_key_sequence (keybuf=0x7ffcdcb7f510, bufsize=30, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false)
    at keyboard.c:9147
#11 0x00000000005918d0 in command_loop_1 () at keyboard.c:1368
#12 0x0000000000646e78 in internal_condition_case (bfun=0x59148c <command_loop_1>, handlers=XIL(0x5220), hfun=0x590a93 <cmd_error>) at eval.c:1332
#13 0x0000000000591066 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1110
#14 0x0000000000646381 in internal_catch (tag=XIL(0xc6c0), func=0x591039 <command_loop_2>, arg=XIL(0)) at eval.c:1097
#15 0x0000000000591004 in command_loop () at keyboard.c:1089
#16 0x000000000059057d in recursive_edit_1 () at keyboard.c:695
#17 0x0000000000590772 in Frecursive_edit () at keyboard.c:766
#18 0x000000000058e31a in main (argc=2, argv=0x7ffcdcb7f9d8) at emacs.c:1713






Reply | Threaded
Open this post in threaded view
|

bug#28710: 27.0.50; eassert failure in maybe_produce_line_number

Eli Zaretskii
> From: Alex <[hidden email]>
> Cc: [hidden email]
> 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.



Reply | Threaded
Open this post in threaded view
|

bug#28710: 27.0.50; eassert failure in maybe_produce_line_number

Eli Zaretskii
> Date: Sun, 08 Oct 2017 12:35:51 +0300
> From: Eli Zaretskii <[hidden email]>
> Cc: [hidden email]
>
> > From: Alex <[hidden email]>
> > Cc: [hidden email]
> > 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.

Seems like some GDB bug or misfeature.  I've asked a question about it
on the GDB list.



Reply | Threaded
Open this post in threaded view
|

bug#28710: 27.0.50; eassert failure in maybe_produce_line_number

Alex-2
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> writes:

> The only difference is the value of cursor_vpos (probably because you
> hit RET on a different line or generally used a different commit?).

Yeah, I'm using a different commit, sorry.

> 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.

The return value appears to be true. The breakpoint does trigger right
after, and enabled_p is also true:

Thread 1 "emacs" hit Hardware watchpoint 4: -location $1->desired_matrix->rows->enabled_p

Old value = false
New value = true
prepare_desired_row (w=0x1695d60 <bss_sbrk_buffer+8894272>, row=0x4182860,
    mode_line_p=true) at dispnew.c:1076
1076      row->reversed_p = rp;
(gdb) c
Continuing.

Thread 1 "emacs" hit Hardware watchpoint 4: -location $1->desired_matrix->rows->enabled_p

Old value = true
New value = false
clear_glyph_matrix_rows (matrix=0x3f524f0, start=0, end=37) at dispnew.c:693
693  for (; start < end; ++start)
(gdb) c
Continuing.

Thread 1 "emacs" hit Hardware watchpoint 4: -location $1->desired_matrix->rows->enabled_p

Old value = false
New value = true
prepare_desired_row (w=0x1695d60 <bss_sbrk_buffer+8894272>, row=0x4182860,
    mode_line_p=false) at dispnew.c:1076
1076      row->reversed_p = rp;
(gdb) break xdisp.c:17039
Breakpoint 5 at 0x474844: file xdisp.c, line 17039.
(gdb) commands
Type commands for breakpoint(s) 5, one per line.
End with a line saying just "end".
>p w->desired_matrix->rows->enabled_p
>end
(gdb) finish
Run till exit from #0  prepare_desired_row (
    w=0x1695d60 <bss_sbrk_buffer+8894272>, row=0x4182860, mode_line_p=false)
    at dispnew.c:1076
display_line (it=0x7ffefb255dc0, cursor_vpos=25) at xdisp.c:21208
warning: Source file is more recent than executable.
21208  row->y = it->current_y;
(gdb) finish
Run till exit from #0  display_line (it=0x7ffefb255dc0, cursor_vpos=25)
    at xdisp.c:21208
0x0000000000477380 in try_window (window=XIL(0x1695d65), pos=..., flags=1)
    at xdisp.c:17592
17592      if (display_line (&it, cursor_vpos))
Value returned is $2 = true
(gdb) finish
Run till exit from #0  0x0000000000477380 in try_window (
    window=XIL(0x1695d65), pos=..., flags=1) at xdisp.c:17592
0x0000000000474866 in redisplay_window (window=XIL(0x1695d65),
    just_this_one_p=false) at xdisp.c:17039
17039  if (try_window (window, startp, TRY_WINDOW_CHECK_MARGINS) < 0)
Value returned is $3 = 1
(gdb) continue
Continuing.

Thread 1 "emacs" hit Breakpoint 5, redisplay_window (window=XIL(0x1695d65), just_this_one_p=false) at xdisp.c:17039
17039  if (try_window (window, startp, TRY_WINDOW_CHECK_MARGINS) < 0)
$4 = true
(gdb) p w->desired_matrix->rows->enabled_p
$5 = true

> 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

I tried it with a different font(size), without byte-compilation, and
with a magit git snapshot -- all still crashed for me. Have you tried
using MELPA[1] to install magit? Maybe that would work.

Footnotes:
[1]  https://magit.vc/manual/magit/Installing-from-an-Elpa-Archive.html#Installing-from-an-Elpa-Archive




Reply | Threaded
Open this post in threaded view
|

bug#28710: 27.0.50; eassert failure in maybe_produce_line_number

Eli Zaretskii
> From: Alex <[hidden email]>
> Cc: [hidden email]
> Date: Sun, 08 Oct 2017 13:05:45 -0600
>
> The return value appears to be true. The breakpoint does trigger right
> after, and enabled_p is also true:
>
> Thread 1 "emacs" hit Hardware watchpoint 4: -location $1->desired_matrix->rows->enabled_p
>
> Old value = false
> New value = true
> prepare_desired_row (w=0x1695d60 <bss_sbrk_buffer+8894272>, row=0x4182860,
>     mode_line_p=true) at dispnew.c:1076
> 1076      row->reversed_p = rp;
> (gdb) c
> Continuing.
>
> Thread 1 "emacs" hit Hardware watchpoint 4: -location $1->desired_matrix->rows->enabled_p
>
> Old value = true
> New value = false
> clear_glyph_matrix_rows (matrix=0x3f524f0, start=0, end=37) at dispnew.c:693
> 693  for (; start < end; ++start)
> (gdb) c
> Continuing.
>
> Thread 1 "emacs" hit Hardware watchpoint 4: -location $1->desired_matrix->rows->enabled_p
>
> Old value = false
> New value = true
> prepare_desired_row (w=0x1695d60 <bss_sbrk_buffer+8894272>, row=0x4182860,
>     mode_line_p=false) at dispnew.c:1076
> 1076      row->reversed_p = rp;
> (gdb) break xdisp.c:17039
> Breakpoint 5 at 0x474844: file xdisp.c, line 17039.
> (gdb) commands
> Type commands for breakpoint(s) 5, one per line.
> End with a line saying just "end".
> >p w->desired_matrix->rows->enabled_p
> >end
> (gdb) finish
> Run till exit from #0  prepare_desired_row (
>     w=0x1695d60 <bss_sbrk_buffer+8894272>, row=0x4182860, mode_line_p=false)
>     at dispnew.c:1076
> display_line (it=0x7ffefb255dc0, cursor_vpos=25) at xdisp.c:21208
> warning: Source file is more recent than executable.
> 21208  row->y = it->current_y;
> (gdb) finish
> Run till exit from #0  display_line (it=0x7ffefb255dc0, cursor_vpos=25)
>     at xdisp.c:21208
> 0x0000000000477380 in try_window (window=XIL(0x1695d65), pos=..., flags=1)
>     at xdisp.c:17592
> 17592      if (display_line (&it, cursor_vpos))
> Value returned is $2 = true
> (gdb) finish
> Run till exit from #0  0x0000000000477380 in try_window (
>     window=XIL(0x1695d65), pos=..., flags=1) at xdisp.c:17592
> 0x0000000000474866 in redisplay_window (window=XIL(0x1695d65),
>     just_this_one_p=false) at xdisp.c:17039
> 17039  if (try_window (window, startp, TRY_WINDOW_CHECK_MARGINS) < 0)
> Value returned is $3 = 1
> (gdb) continue
> Continuing.
>
> Thread 1 "emacs" hit Breakpoint 5, redisplay_window (window=XIL(0x1695d65), just_this_one_p=false) at xdisp.c:17039
> 17039  if (try_window (window, startp, TRY_WINDOW_CHECK_MARGINS) < 0)
> $4 = true
> (gdb) p w->desired_matrix->rows->enabled_p
> $5 = true

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.

Also, please recompile Emacs because:

> warning: Source file is more recent than executable.

Thanks.

> Have you tried using MELPA[1] to install magit? Maybe that would
> work.

I'm not sure how will this help.  I don't want to install Magit, I
just use it from a directory where I unzipped its snapshot.  How using
MELPA would change that?



Reply | Threaded
Open this post in threaded view
|

bug#28710: 27.0.50; eassert failure in maybe_produce_line_number

Alex-2
Eli Zaretskii <[hidden email]> 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

Old value = false
New value = true
prepare_desired_row (w=0x15cac30 <bss_sbrk_buffer+8062480>, row=0x4827bc0, mode_line_p=false) at dispnew.c:1076
1076      row->reversed_p = rp;
(gdb) b xdisp.c:17039
Breakpoint 3 at 0x474844: file xdisp.c, line 17039.
(gdb) commands
Type commands for breakpoint(s) 3, one per line.
End with a line saying just "end".
>p w->desired_matrix->rows->enabled_p
>end
(gdb) finish
Run till exit from #0  prepare_desired_row (
    w=0x15cac30 <bss_sbrk_buffer+8062480>, row=0x4827bc0, mode_line_p=false)
    at dispnew.c:1076
display_line (it=0x7ffd11e08a20, cursor_vpos=26) at xdisp.c:21208
21208  row->y = it->current_y;
(gdb) finish
Run till exit from #0  display_line (it=0x7ffd11e08a20, cursor_vpos=26)
    at xdisp.c:21208
0x0000000000477380 in try_window (window=..., pos=..., flags=1)
    at xdisp.c:17592
17592      if (display_line (&it, cursor_vpos))
Value returned is $2 = true
(gdb) finish
Run till exit from #0  0x0000000000477380 in try_window (window=..., pos=...,
    flags=1) at xdisp.c:17592
0x0000000000474866 in redisplay_window (window=..., just_this_one_p=false)
    at xdisp.c:17039
17039  if (try_window (window, startp, TRY_WINDOW_CHECK_MARGINS) < 0)
Value returned is $3 = 1
(gdb) n
17046      if (f->fonts_changed)
(gdb)
17049      if (w->cursor.vpos >= 0)
(gdb)
17051  if (!just_this_one_p
(gdb)
17055    w->base_line_number = 0;
(gdb)
17057  if (!cursor_row_fully_visible_p (w, true, false))
(gdb)
17064    goto done;
(gdb)
17393  SET_TEXT_POS_FROM_MARKER (startp, w->start);
(gdb)
17394  w->start_at_line_beg = (CHARPOS (startp) == BEGV
(gdb)
17395  || FETCH_BYTE (BYTEPOS (startp) - 1) == '\n');
(gdb)
17394  w->start_at_line_beg = (CHARPOS (startp) == BEGV
(gdb)
17398  if ((update_mode_line
(gdb)
17412      && (window_wants_mode_line (w)
(gdb)

17416      display_mode_lines (w);
(gdb)
17420      if (window_wants_mode_line (w)
(gdb)
17421  && CURRENT_MODE_LINE_HEIGHT (w) != DESIRED_MODE_LINE_HEIGHT (w))
(gdb)
17431      if (window_wants_header_line (w)
(gdb)
17440      if (f->fonts_changed)
(gdb)
17444  if (!line_number_displayed && w->base_line_pos != -1)
(gdb)
17450 finish_menu_bars:
(gdb)
17454  if (update_mode_line
(gdb)
17455      && EQ (FRAME_SELECTED_WINDOW (f), window))
(gdb)
17459      if (FRAME_WINDOW_P (f))
(gdb)
17463  redisplay_menu_p = FRAME_EXTERNAL_MENU_BAR (f);
(gdb)
17471      if (redisplay_menu_p)
(gdb)
17472        display_menu_bar (w);
(gdb)
17475      if (FRAME_WINDOW_P (f))
(gdb)
17478  if (FRAME_EXTERNAL_TOOL_BAR (f))
(gdb)
17479    redisplay_tool_bar (f);
(gdb)
17488      x_consider_frame_title (w->frame);
(gdb)
17493  if (FRAME_WINDOW_P (f)
(gdb)
17496    || w->pseudo_window_p)))
(gdb)
17495    || (!used_current_matrix_p && !overlay_arrow_seen)
(gdb)
17494      && update_window_fringes (w, (just_this_one_p
(gdb)
17511  if (WINDOW_BOTTOM_DIVIDER_WIDTH (w))
(gdb)
17519 need_larger_matrices:
(gdb)
17523   if (WINDOW_HAS_VERTICAL_SCROLL_BAR (w) || WINDOW_HAS_HORIZONTAL_SCROLL_BAR (w))
(gdb)
17525      if (WINDOW_HAS_VERTICAL_SCROLL_BAR (w))
(gdb)
17527 set_vertical_scroll_bar (w);
(gdb)
17529      if (WINDOW_HAS_HORIZONTAL_SCROLL_BAR (w))
(gdb)
17535      if (FRAME_TERMINAL (f)->redeem_scroll_bar_hook)
(gdb)
17536        (*FRAME_TERMINAL (f)->redeem_scroll_bar_hook) (w);
(gdb)

17542  if (CHARPOS (opoint) < BEGV)
(gdb)
17544  else if (CHARPOS (opoint) > ZV)
(gdb)
17547    TEMP_SET_PT_BOTH (CHARPOS (opoint), BYTEPOS (opoint));
(gdb)
17549  set_buffer_internal_1 (old);
(gdb)
17552  if (CHARPOS (lpoint) <= ZV)
(gdb)
17553    TEMP_SET_PT_BOTH (CHARPOS (lpoint), BYTEPOS (lpoint));
(gdb)
17555  unbind_to (count, Qnil);
(gdb)
17556 }
(gdb)
redisplay_window_0 (window=...) at xdisp.c:14800
14800  return Qnil;
(gdb)
14801 }
(gdb)
internal_condition_case_1 (bfun=0x46cfbf <redisplay_window_0>, arg=..., handlers=..., hfun=0x46cf87 <redisplay_window_error>) at eval.c:1357
1357      eassert (handlerlist == c);
(gdb)
1358      handlerlist = c->next;
(gdb)
1359      return val;
(gdb)
1361 }
(gdb)
redisplay_windows (window=...) at xdisp.c:14784
14784      window = w->next;
(gdb)
14768  while (!NILP (window))
(gdb)
14770      struct window *w = XWINDOW (window);
(gdb)
14772      if (WINDOWP (w->contents))
(gdb)
14774      else if (BUFFERP (w->contents))
(gdb)
14776  displayed_buffer = XBUFFER (w->contents);
(gdb)
14779  internal_condition_case_1 (redisplay_window_0, window,
(gdb)
14784      window = w->next;
(gdb)
14768  while (!NILP (window))
(gdb)
14786 }
(gdb)
redisplay_internal () at xdisp.c:14275
14275      if (!FRAME_LIVE_P (f))
(gdb)
14280      if (gcscrollbars && FRAME_TERMINAL (f)->judge_scroll_bars_hook)
(gdb)
14281 FRAME_TERMINAL (f)->judge_scroll_bars_hook (f);
(gdb)
14283      if (FRAME_VISIBLE_P (f) && !FRAME_OBSCURED_P (f))
(gdb)
14286  if (f->fonts_changed)
(gdb)
14298  if (!f->already_hscrolled_p)
(gdb)
14300      f->already_hscrolled_p = true;
(gdb)
14301                      if (hscroll_retries <= MAX_HSCROLL_RETRIES
(gdb)
14302                          && hscroll_windows (f->root_window))
(gdb)
14320  if (!f_redisplay_flag && f->redisplay)
(gdb)
14321                    goto retry_frame;
(gdb)
14256  if (FRAME_WINDOW_P (f) || FRAME_TERMCAP_P (f) || f == sf)
(gdb)
14260 = f->redisplay || !REDISPLAY_SOME_P ();
(gdb)
14258      bool gcscrollbars
(gdb)
14261      bool f_redisplay_flag = f->redisplay;
(gdb)
14264      if (gcscrollbars && FRAME_TERMINAL (f)->condemn_scroll_bars_hook)
(gdb)
14265 FRAME_TERMINAL (f)->condemn_scroll_bars_hook (f);
(gdb)
14267      if (FRAME_VISIBLE_P (f) && !FRAME_OBSCURED_P (f))
(gdb)
14268 redisplay_windows (FRAME_ROOT_WINDOW (f));
(gdb)

Thread 1 "emacs" hit Breakpoint 3, redisplay_window (window=..., just_this_one_p=false) at xdisp.c:17039
17039  if (try_window (window, startp, TRY_WINDOW_CHECK_MARGINS) < 0)
$4 = true
(gdb)

Thread 1 "emacs" received signal SIGABRT, Aborted.
raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:51

>> Have you tried using MELPA[1] to install magit? Maybe that would
>> work.
>
> I'm not sure how will this help.  I don't want to install Magit, I
> just use it from a directory where I unzipped its snapshot.  How using
> MELPA would change that?

I'm not sure how either; MELPA was just on my mind since that's how I'm
using Magit's dependencies.



Reply | Threaded
Open this post in threaded view
|

bug#28710: 27.0.50; eassert failure in maybe_produce_line_number

Eli Zaretskii
> From: Alex <[hidden email]>
> Cc: [hidden email]
> Date: Sun, 08 Oct 2017 15:19:53 -0600
>
> Eli Zaretskii <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

bug#28710: 27.0.50; eassert failure in maybe_produce_line_number

Eli Zaretskii
In reply to this post by Eli Zaretskii
> Date: Sun, 08 Oct 2017 13:09:30 +0300
> From: Eli Zaretskii <[hidden email]>
> Cc: [hidden email]
>
> > > 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.
>
> Seems like some GDB bug or misfeature.  I've asked a question about it
> on the GDB list.

The conclusion is that it's a bug, so it will be fixed in a future
version of GDB.  If you can patch and rebuild your GDB, a patch that
worked for me and that applies to GDB 8.0 is here:

  https://sourceware.org/ml/gdb/2017-10/msg00029.html



Reply | Threaded
Open this post in threaded view
|

bug#28710: 27.0.50; eassert failure in maybe_produce_line_number

Alex-2
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> writes:


> Thanks.  I installed a change that should fix the problem, please try
> the latest emacs-26 branch.

Looks like it's fixed, thanks.

> 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.

Unfortunately, when I try to use XFRAME, I get:
  No symbol "__builtin_assume_aligned" in current context.

I tried the following workaround, but no backtraces showed up:

Thread 1 "emacs-26.0.60.4" hit Breakpoint 1, Fredraw_display ()
    at dispnew.c:3032
3032  FOR_EACH_FRAME (tail, frame)
(gdb) n
3033    if (FRAME_VISIBLE_P (XFRAME (frame)))
(gdb) p (struct frame *) XLI(frame) - Lisp_Vectorlike
$3 = (struct frame *) 0x15c9285 <bss_sbrk_buffer+8055909>
(gdb) p $3->redisplay
$4 = false
(gdb) watch -l $3->redisplay
Hardware watchpoint 2: -location $3->redisplay
(gdb) commands
Type commands for breakpoint(s) 2, one per line.
End with a line saying just "end".
>bt
>continue
>end
(gdb) c
Continuing.

Thread 1 "emacs-26.0.60.4" received signal SIGABRT, Aborted.



Reply | Threaded
Open this post in threaded view
|

bug#28710: 27.0.50; eassert failure in maybe_produce_line_number

Eli Zaretskii
> From: Alex <[hidden email]>
> Cc: [hidden email]
> Date: Mon, 09 Oct 2017 11:56:20 -0600
>
> > Thanks.  I installed a change that should fix the problem, please try
> > the latest emacs-26 branch.
>
> Looks like it's fixed, thanks.

Great, thanks for testing.

> >   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.
>
> Unfortunately, when I try to use XFRAME, I get:
>   No symbol "__builtin_assume_aligned" in current context.

OK, then you could use a slightly different way:

  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 frame
  $1 = XIL(0xa000000001b5e380)
  (gdb) xframe
  $2 = (struct frame *) 0x1b5e380 <dumped_data+4020672>
  "emacs@HOME-C4E4A596F7"
  (gdb) p $2->redisplay
  $3 = true
  (gdb) watch -l $2->redisplay
  Hardware watchpoint 4: -location $2->redisplay
  (gdb) commands
  Type commands for breakpoint(s) 4, one per line.
  End with a line saying just "end".
    >bt
    >continue
    >end
  (gdb) continue

(The "xframe" command is defined in src/.gdbinit, so if you are not
running GDB from the src directory, you will need to tell it to read
that file:

  (gdb) source /path/to/emacs/src/.gdbinit

> I tried the following workaround, but no backtraces showed up:
>
> Thread 1 "emacs-26.0.60.4" hit Breakpoint 1, Fredraw_display ()
>     at dispnew.c:3032
> 3032  FOR_EACH_FRAME (tail, frame)
> (gdb) n
> 3033    if (FRAME_VISIBLE_P (XFRAME (frame)))
> (gdb) p (struct frame *) XLI(frame) - Lisp_Vectorlike
> $3 = (struct frame *) 0x15c9285 <bss_sbrk_buffer+8055909>

When I try this, I get a different frame pointer and a warning message
from GDB.  So let's hope this workaround is incorrect ;-)

Thanks.



Reply | Threaded
Open this post in threaded view
|

bug#28710: 27.0.50; eassert failure in maybe_produce_line_number

Alex-2
Eli Zaretskii <[hidden email]> writes:

> OK, then you could use a slightly different way:
>
>   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 frame
>   $1 = XIL(0xa000000001b5e380)
>   (gdb) xframe
>   $2 = (struct frame *) 0x1b5e380 <dumped_data+4020672>
>   "emacs@HOME-C4E4A596F7"
>   (gdb) p $2->redisplay
>   $3 = true
>   (gdb) watch -l $2->redisplay
>   Hardware watchpoint 4: -location $2->redisplay
>   (gdb) commands
>   Type commands for breakpoint(s) 4, one per line.
>   End with a line saying just "end".
>     >bt
>     >continue
>     >end
>   (gdb) continue

Okay, I got the second backtrace after pressing RET:

Thread 1 "emacs" hit Hardware watchpoint 4: -location $2->redisplay

Old value = true
New value = false
redisplay_internal () at xdisp.c:14366
14366  f->garbaged = false;
#0  0x000000000046bd61 in redisplay_internal () at xdisp.c:14366
#1  0x00000000004690da in redisplay () at xdisp.c:13488
#2  0x0000000000594cb1 in read_char (commandflag=1, map=XIL(0x541d1c3), prev_event=XIL(0), used_mouse_menu=0x7ffd34b0a21f, end_time=0x0) at keyboard.c:2480
#3  0x00000000005a500f in read_key_sequence (keybuf=0x7ffd34b0a370, bufsize=30, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false)
    at keyboard.c:9147
#4  0x00000000005918e2 in command_loop_1 () at keyboard.c:1368
#5  0x0000000000646e96 in internal_condition_case (bfun=0x59149e <command_loop_1>, handlers=XIL(0x5220), hfun=0x590aa5 <cmd_error>) at eval.c:1332
#6  0x0000000000591078 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1110
#7  0x000000000064639f in internal_catch (tag=XIL(0xc6c0), func=0x59104b <command_loop_2>, arg=XIL(0)) at eval.c:1097
#8  0x0000000000591016 in command_loop () at keyboard.c:1089
#9  0x000000000059058f in recursive_edit_1 () at keyboard.c:695
#10 0x0000000000590784 in Frecursive_edit () at keyboard.c:766
#11 0x000000000058e32c in main (argc=2, argv=0x7ffd34b0a838) at emacs.c:1713

Lisp Backtrace:
"redisplay_internal (C function)" (0x0)

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
#5  0x000000000046d001 in redisplay_window_0 (window=XIL(0x15cbc35)) at xdisp.c:14799
#6  0x0000000000646f71 in internal_condition_case_1 (bfun=0x46cfbf <redisplay_window_0>, arg=XIL(0x15cbc35), handlers=XIL(0xe82d93), hfun=0x46cf87 <redisplay_window_error>) at eval.c:1356
#7  0x000000000046cf5c in redisplay_windows (window=XIL(0x15cbc35)) at xdisp.c:14779
#8  0x000000000046b8f5 in redisplay_internal () at xdisp.c:14268
#9  0x00000000004690da in redisplay () at xdisp.c:13488
#10 0x0000000000594cb1 in read_char (commandflag=1, map=XIL(0x55117d3), prev_event=XIL(0), used_mouse_menu=0x7ffd34b0a21f, end_time=0x0) at keyboard.c:2480
#11 0x00000000005a500f in read_key_sequence (keybuf=0x7ffd34b0a370, bufsize=30, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false)
    at keyboard.c:9147
#12 0x00000000005918e2 in command_loop_1 () at keyboard.c:1368
#13 0x0000000000646e96 in internal_condition_case (bfun=0x59149e <command_loop_1>, handlers=XIL(0x5220), hfun=0x590aa5 <cmd_error>) at eval.c:1332
#14 0x0000000000591078 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1110
#15 0x000000000064639f in internal_catch (tag=XIL(0xc6c0), func=0x59104b <command_loop_2>, arg=XIL(0)) at eval.c:1097
#16 0x0000000000591016 in command_loop () at keyboard.c:1089
#17 0x000000000059058f in recursive_edit_1 () at keyboard.c:695
#18 0x0000000000590784 in Frecursive_edit () at keyboard.c:766
#19 0x000000000058e32c in main (argc=2, argv=0x7ffd34b0a838) at emacs.c:1713



Reply | Threaded
Open this post in threaded view
|

bug#28710: 27.0.50; eassert failure in maybe_produce_line_number

Eli Zaretskii
> From: Alex <[hidden email]>
> Cc: [hidden email]
> 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.