From: 路客 <luke.yx.lee@gmail.com>
To: 46586@debbugs.gnu.org
Subject: bug#46586: 26.3, 27.1.50; Emacs crash in a backtrace (core) dump (a long standing issue)
Date: Wed, 17 Feb 2021 18:13:56 +0800 [thread overview]
Message-ID: <CAA=xLRNqaKXrDsX9BCv7rthUWUcuPczW+arVvWKfo3nS6mZwxA@mail.gmail.com> (raw)
Hi all,
I found a short data clip can always crash Emacs 26.3 or 27.1.50 with
a terminal backtrace (core) dump in the "read()" function. It took me
a few hours to narrow it down and finally reach this minimal crashing
data set:
----- code begin -----
(#1=(#("000008964 .gnus.el" 0 18 (r #1#))
(def #2=#("000008964 .gnus.el" 0 18
(r
(#2#
(def #3=#("000006393 .gnus.el" 0 18
(r #4=(#3#
(def
#("000006393 .gnus.el" 0 18 (r #4#)) "x"))))"x"))))"x")))
----- code end -----
Try to `read' or `eval' this block of code (C-x C-e) will immediately
crash Emacs 26.3 or 27.1.50; however, older Emacs 26.0.50 works well
by entering the debugger with an error like:
----- elisp debugger message begin -----
Debugger entered--Lisp error: (invalid-function (#("000008964
.gnus.el" 0 18 (r #1)) (def #("000008964 .gnus.el" 0 18 (r (#3 (def
#("000006393 .gnus.el" 0 18 (r (#7 (def #("000006393 .gnus.el" 0 18 (r
#9)) "x")))) "x")))) "x")))
((#("000008964 .gnus.el" 0 18 (r #1)) (def #("000008964 .gnus.el" 0
18 (r (#3 (def #("000006393 .gnus.el" 0 18 ...) "x")))) "x")))
eval(((#("000008964 .gnus.el" 0 18 (r #2)) (def #("000008964
.gnus.el" 0 18 (r (#4 (def #("000006393 .gnus.el" 0 18 ...) "x"))))
"x"))) nil)
elisp--eval-last-sexp(nil)
eval-last-sexp(nil)
funcall-interactively(eval-last-sexp nil)
call-interactively(eval-last-sexp nil nil)
command-execute(eval-last-sexp)
----- elisp debugger message end -----
Funny thing is that if I change any of the above ".gnus.el" to another
file name, Emacs won't crash and is able to enter the debugger like
26.0.50. Is there anything special about the ".gnus.el" ?
This short crashing code block was actually a lot longer as a part of
a big bookmark file, and has long ago started to crash newer Emacs
than 26.0.50. I didn't know the root cause till these days I decided
to figure that out and finally extracted that block out and simplified
it to this simple form.
Could anyone help fix this long standing issue? Thanks.
--
Best regards,
Luke Lee
next reply other threads:[~2021-02-17 10:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-17 10:13 路客 [this message]
2021-02-17 16:04 ` bug#46586: 26.3, 27.1.50; Emacs crash in a backtrace (core) dump (a long standing issue) Eli Zaretskii
2021-02-18 1:56 ` 路客
2021-02-18 14:16 ` Eli Zaretskii
2021-02-18 14:45 ` Andreas Schwab
2021-02-18 15:00 ` Eli Zaretskii
2022-06-17 15:25 ` Lars Ingebrigtsen
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='CAA=xLRNqaKXrDsX9BCv7rthUWUcuPczW+arVvWKfo3nS6mZwxA@mail.gmail.com' \
--to=luke.yx.lee@gmail.com \
--cc=46586@debbugs.gnu.org \
/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.