bug#71224: 30.0.50; SIGSEGV in start_display

[Daniel Clemente]

Sorry for the long wait, I was focused on other bugs.
This one is about the null glyph matrices.
It still happens after the fixes in 71223 that improve fast
opening+closing. I'm using 7d36bb0547f, fairly recent.

After a few hours of debugging and learning. I found a very simple
formula to produce the SIGSEGV. No GC involved, and no automated
window opening/resizing.
To reproduce it:

emacs --fg-daemon -Q
emacsclient -c

Open a buffer with this code in it:
(defun recurse () (recurse))
(recurse)

And eval the defun. Don't call (recurse) yet.

Do: M-x debug
This opens the backtrace window.
Use C-x o  to go away from the backtrace window and back to that
buffer with the Lisp code.
Now eval (with C-x C-e) the call to (recurse)
You get a message in the minibuffer: cl-prin1, excessive-lisp-nesting,
and the backtrace window is updated.
Don't close that backtrace window.

Open a new frame, as before: emacsclient -c
The daemon crashes with SIGSEGV.


Program received signal SIGSEGV, Segmentation fault.
0x00005555555d7833 in redisplay_window (window=XIL(0x55555631d5e5),
just_this_one_p=false) at xdisp.c:19961
19961      *w->desired_matrix->method = 0;
(gdb) bt
#0  0x00005555555d7833 in redisplay_window
(window=XIL(0x55555631d5e5), just_this_one_p=false)
    at xdisp.c:19961
#1  0x00005555555d0a95 in redisplay_window_0
(window=XIL(0x55555631d5e5)) at xdisp.c:18016
#2  0x000055555576c9e2 in internal_condition_case_1
(bfun=0x5555555d0a53 <redisplay_window_0>,
    arg=XIL(0x55555631d5e5), handlers=XIL(0x7ffff1e5506b),
hfun=0x5555555d0931 <redisplay_window_error>)
    at eval.c:1637
#3  0x00005555555d0907 in redisplay_windows
(window=XIL(0x55555631d5e5)) at xdisp.c:17985
#4  0x00005555555cf486 in redisplay_internal () at xdisp.c:17384
#5  0x00005555555cffcc in redisplay_preserve_echo_area (from_where=2)
at xdisp.c:17743
#6  0x00005555555950e6 in Fredisplay (force=XIL(0)) at dispnew.c:6368



I tried to use watchpoints to track w->desired_matrix or
w->current_matrix but found it difficult because of what I explain
below.
In particular, if I set the watchpoint *after* I get the SIGSEGV, then
isn't it too late? Next time I run the program I may be seeing
something else in that part of the memory.


> > A next step for me could be setting up a breakpoint (or message) in
> > the place where the glyph matrix is defined, to see if it's ever being
> > defined, vs. it's defined and then cleared. But I'm still learning
> > about glyph matrices and I don't know where they're expected vs. where
> > null.
>
> AFAIK, the glyph matrices are assigned to windows on TTY frames in
> allocate_matrices_for_frame_redisplay:
>
>           /* If not already done, allocate sub-matrix structures.  */
>           if (w->desired_matrix == NULL)
>             {
>               w->desired_matrix = new_glyph_matrix (f->desired_pool);
>               w->current_matrix = new_glyph_matrix (f->current_pool);
>               *window_change_flags |= NEW_LEAF_MATRIX;
>             }
>
> And new_glyph_matrix cannot return NULL (if we run out of memory,
> new_glyph_matrix will signal a "memory-full" error).
>
> It might be possible that the glyph matrices of a window are somehow
> freed later, perhaps in free_window_matrices.  But all these places
> are run as part of deleting a window under block_input, so I don't
> quite see how a window with NULL glyph matrices could have been used
> for anything...
>
> > I'm also trying to get better at gdb to detect when a variable (e.g.
> > w->desired_matrix) changes.
>
> You are talking about watchpoints.  Something like
>
>   (gdb) watch -l w->current_matrix
>

While doing that, I saw some normal changes like
Old value = (glyph_matrix *) 0x1b000a006d37325b
New value = (glyph_matrix *) 0x1b000a006d373220


But if I wait for situations when w->current_matrix becomes nil… well,
I'm seeing many weird cases like the ones I post below, but I think
they're not valuable, so you can skip them.
It feels like I'm watching (with the watchpoint) a memory position
that *was* storing w->current_matrix but is now being used for other
things. I see how others (e.g. init_tty below) reuse that memory
position for other things. I hope this is not a case of a buffer
overflow (i.e. the glyph_matrix being null not because someone
explicitly freed it, but because some other code overwrote that value
with 0x0).


Hardware watchpoint 2: -location w->current_matrix

Old value = (glyph_matrix *) 0x1b000a006d37325b
New value = (glyph_matrix *) 0x0
__memset_avx2_unaligned_erms () at
../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:336
336    ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S: No
such file or directory.
#0  __memset_avx2_unaligned_erms () at
../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:336
#1  0x000055555572a256 in lmalloc (size=8824, clearit=true) at alloc.c:1402
#2  0x0000555555729693 in xzalloc (size=8824) at alloc.c:789
#3  0x0000555555675856 in init_tty (name=0x7fffffff9fd0 "/dev/pts/21",
terminal_type=0x7fffffff9fb0 "rxvt-unicode-256color",
must_succeed=false)
    at term.c:4140
#4  0x000055555559a694 in Fmake_terminal_frame
(parms=XIL(0x7ffff19a7a83)) at frame.c:1414

Lisp Backtrace:
"make-terminal-frame" (0xf0dff188)
"tty-create-frame-with-faces" (0xf0dff150)
0xf1aa00d0 PVEC_CLOSURE
"apply" (0xf0dff0c8)
"frame-creation-function" (0xf0dff068)
"make-frame" (0xffffae08)
"server--create-frame" (0xffffb0b8)
"server-create-tty-frame" (0xffffb318)
"server--process-filter-1" (0xffffb4f8)
"server--process-filter-all-pending" (0xffffb680)
"server-process-filter" (0xffffb7f8)


Another one; it happened just the first time I'm doing the
opening+closing of frames.

Hardware watchpoint 2: -location w->current_matrix

Old value = <unreadable>
New value = (glyph_matrix *) 0x0
__memset_avx2_unaligned_erms () at
../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:336
336    ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S: No
such file or directory.
#0  __memset_avx2_unaligned_erms () at
../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:336
#1  0x00005555555850d2 in memclear (p=0x55555631e090, nbytes=272160)
at /w/emacs/src/lisp.h:2030
#2  0x0000555555589719 in realloc_glyph_pool (pool=0x5555561860f0,
matrix_dim=...) at dispnew.c:1401
#3  0x000055555558a805 in adjust_frame_glyphs_for_frame_redisplay
(f=0x55555622b8f0) at dispnew.c:2077
#4  0x0000555555589dfd in adjust_frame_glyphs (f=0x55555622b8f0) at
dispnew.c:1850
#5  0x0000555555599211 in adjust_frame_size (f=0x55555622b8f0,
new_text_width=90, new_text_height=62, inhibit=5, pretend=false,
    parameter=XIL(0xf720)) at frame.c:898
#6  0x000055555559a7a3 in Fmake_terminal_frame
(parms=XIL(0x7ffff1998fa3)) at frame.c:1424
#7  0x0000555555770a5b in funcall_subr (subr=0x555555eb0020
<Smake_terminal_frame>, numargs=1, args=0x7ffff0dff188) at eval.c:3161

Lisp Backtrace:
"make-terminal-frame" (0xf0dff188)
"tty-create-frame-with-faces" (0xf0dff150)
0xf1aa00d0 PVEC_CLOSURE
"apply" (0xf0dff0c8)
"frame-creation-function" (0xf0dff068)
"make-frame" (0xffffae08)
"server--create-frame" (0xffffb0b8)
"server-create-tty-frame" (0xffffb318)
"server--process-filter-1" (0xffffb4f8)
"server--process-filter-all-pending" (0xffffb680)
"server-process-filter" (0xffffb7f8)


Another case in which it was set to 0:

Hardware watchpoint 2: -location w->current_matrix

Old value = (glyph_matrix *) 0x55555618f98d
New value = (glyph_matrix *) 0x0
__memset_avx2_unaligned_erms () at
../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:336
336    ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S: No
such file or directory.
#0  __memset_avx2_unaligned_erms () at
../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:336
#1  0x00005555555850d2 in memclear (p=0x55555631b2c0, nbytes=267840)
at /w/emacs/src/lisp.h:2030
#2  0x0000555555589719 in realloc_glyph_pool (pool=0x5555561fc660,
matrix_dim=...) at dispnew.c:1401
#3  0x000055555558a7e8 in adjust_frame_glyphs_for_frame_redisplay
(f=0x555556270c70) at dispnew.c:2076
#4  0x0000555555589dfd in adjust_frame_glyphs (f=0x555556270c70) at
dispnew.c:1850
#5  0x0000555555599211 in adjust_frame_size (f=0x555556270c70,
new_text_width=90, new_text_height=61, inhibit=5, pretend=false,
    parameter=XIL(0xf720)) at frame.c:898
#6  0x000055555559a7a3 in Fmake_terminal_frame
(parms=XIL(0x7ffff194b943)) at frame.c:1424
#7  0x0000555555770a5b in funcall_subr (subr=0x555555eb0020
<Smake_terminal_frame>, numargs=1, args=0x7ffff0dff188) at eval.c:3161

Lisp Backtrace:
"make-terminal-frame" (0xf0dff188)
"tty-create-frame-with-faces" (0xf0dff150)
0xf1aa00d0 PVEC_CLOSURE
"apply" (0xf0dff0c8)
"frame-creation-function" (0xf0dff068)
"make-frame" (0xffffae08)
"server--create-frame" (0xffffb0b8)
"server-create-tty-frame" (0xffffb318)
"server--process-filter-1" (0xffffb4f8)
"server--process-filter-all-pending" (0xffffb680)
"server-process-filter" (0xffffb7f8)



In other cases, that memory position doesn't look like a pointer
anymore, e.g. that 0x10bf0 below.

Hardware watchpoint 2: -location w->current_matrix

Old value = (struct glyph_matrix *) 0x10bf0
New value = (struct glyph_matrix *) 0xd
build_marker (buf=0x5555562c6c60, charpos=13, bytepos=13) at alloc.c:4066
4066      m->insertion_type = 0;
#0  build_marker (buf=0x5555562c6c60, charpos=13, bytepos=13) at alloc.c:4066
#1  0x0000555555756a62 in Fpoint_marker () at editfns.c:202
#2  0x00005555557584d4 in save_excursion_save (pdl=0x555556164c30) at
editfns.c:782
#3  0x000055555577235c in record_unwind_protect_excursion () at eval.c:3660
#4  0x00005555556c8b57 in Fkill_buffer
(buffer_or_name=XIL(0x5555562c6c65)) at buffer.c:1917
#5  0x0000555555770a5b in funcall_subr (subr=0x555555eba460
<Skill_buffer>, numargs=1, args=0x7ffff0dff0a0) at eval.c:3161
#6  0x00005555557ccdda in exec_byte_code (fun=XIL(0x5555562c708d),
args_template=0, nargs=0, args=0x7fffffffa3b0) at bytecode.c:812
#7  0x00005555557710d4 in funcall_lambda (fun=XIL(0x5555562c708d),
nargs=0, arg_vector=0x7fffffffa3b0) at eval.c:3252

Lisp Backtrace:
"kill-buffer" (0xf0dff0a0)
0x562c7088 PVEC_CLOSURE
"pp-to-string" (0xffffa698)
"pp" (0xffffa838)
"server-eval-and-print" (0xffffaa00)
"server-execute" (0xf0dff038)
0x5660f010 PVEC_CLOSURE
"server-execute-continuation" (0xffffb310)
"server--process-filter-1" (0xffffb4f8)
"server--process-filter-all-pending" (0xffffb680)
"server-process-filter" (0xffffb7f8)