From: Eli Zaretskii <eliz@gnu.org>
To: justksqsf@gmail.com
Cc: 65060@debbugs.gnu.org
Subject: bug#65060: 29.1.50; display_count_lines segv
Date: Sat, 12 Aug 2023 09:50:20 +0300 [thread overview]
Message-ID: <835y5kg3f7.fsf@gnu.org> (raw)
In-Reply-To: <83wmyat3b2.fsf@gnu.org> (message from Eli Zaretskii on Sat, 05 Aug 2023 09:24:01 +0300)
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.
>
>
>
>
next prev parent reply other threads:[~2023-08-12 6:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-04 21:41 bug#65060: 29.1.50; display_count_lines segv Kai Ma
2023-08-05 6:24 ` Eli Zaretskii
2023-08-12 6:50 ` Eli Zaretskii [this message]
2023-08-12 7:28 ` Kai Ma
2023-08-12 8:41 ` Eli Zaretskii
2023-08-12 11:56 ` Kai Ma
2023-08-12 12:08 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=835y5kg3f7.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=65060@debbugs.gnu.org \
--cc=justksqsf@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.