bug#65060: 29.1.50; display_count_lines segv

[Eli Zaretskii]

Ping!  Can you please help me finish investigating this bug by
providing the information I asked for?  Armed with that information, I
think I will be able to find a solution.

> Cc: 65060@debbugs.gnu.org
> Date: Sat, 05 Aug 2023 09:24:01 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Kai Ma <justksqsf@gmail.com>
> > Date: Sat, 05 Aug 2023 05:41:54 +0800
> > 
> > 
> > Emacs can crash due to memchr on null pointers inside
> > display_count_lines:
> > 
> > * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
> > (code=1, address=0x0)
> >     frame #0: 0x00007ff813c6329d 
> > libsystem_platform.dylib`_platform_memchr$VARIANT$Haswell + 29
> >   * frame #1: 0x000000010005c1ef emacs`display_count_lines(start_byte=1, 
> > limit_byte=650, count=17166, byte_pos_ptr=0x00007ff7bfef2ef8) at 
> > xdisp.c:28475:14
> 
> This crash is inside redisplay, which displays the mode line.  That
> calls some Lisp (probably because some mode-line element uses :eval),
> which calls format-mode-line (a _really_ bad idea), which again calls
> Lisp (due to :eval?), which calls line-number-at-pos, which crashes.
> 
> > I took a quick look at the function, and it turns out the cursor can be
> > null even on the first iteration.  After applying the following change,
> > I can see "cursor is null" printed out just before the crash.
> > 
> > diff --git a/src/xdisp.c b/src/xdisp.c
> > index 9cddcfeda27..f994021bb3c 100644
> > --- a/src/xdisp.c
> > +++ b/src/xdisp.c
> > @@ -28457,6 +28457,8 @@ display_count_lines (ptrdiff_t start_byte,
> >       ceiling = min (limit_byte - 1, ceiling);
> >       ceiling_addr = BYTE_POS_ADDR (ceiling) + 1;
> >       base = (cursor = BYTE_POS_ADDR (start_byte));
> > +     if (! cursor)
> > +       fprintf (stderr, "cursor is null\n");
> 
> That's most probably a sign of some other bug elsewhere.
> BYTE_POS_ADDR returns the pointer to buffer text, so it cannot be a
> NULL pointer, unless something really catastrophic happened, like the
> current buffer was killed behind redisplay's back.
> 
> Please add to the fprintf the following data:
> 
>   GPT_BYTE
>   GAP_SIZE
>   BEG_ADDR
>   current_buffer->text->beg
> 
> and show the result.
> 
> My guess is that current_buffer->text->beg is NULL, which means the
> current buffer was killed, and then the bug is where this happens, not
> in display_count_lines.  Most probably, dirvish does something that
> kills the buffer that is the current one when format-mode-line is
> called.
> 
> > 1. Create init.el
> > 
> >     (require 'package)
> >     (add-to-list 'package-archives '("melpa" . 
> > "https://melpa.org/packages/";) t)
> >     (use-package dirvish :ensure t :config (dirvish-override-dired-mode))
> >     (global-display-line-numbers-mode +1)
> >     (dirvish-override-dired-mode)
> > 
> > 2. emacs -q -l init.el
> > 
> > 3. M-x dirvish
> > 
> > 4. randomly kill dirvish buffers, and/or randomly delete dirvish windows.
> > 
> > Chances are, at some point, Emacs crashes due to the above segv.  I have
> > reproduced the crash in emacs -q, but it was not easy.  I will try to
> > find a better recipe and post it here.
> 
> I tried to use this, but couldn't cause Emacs crash.  And I don't
> think the reproduction is really necessary, if we establish that the
> current buffer is dead when format-mode-line is called in this case.
> 
> 
> 
>