From: Eli Zaretskii <eliz@gnu.org>
To: Noam Postavsky <npostavs@gmail.com>
Cc: michael_heerdegen@web.de, joostkremers@fastmail.fm,
40088@debbugs.gnu.org, monnier@iro.umontreal.ca
Subject: bug#40088: 27.0.90; Symbol’s value as variable is void: debugger-outer-match-data
Date: Sun, 22 Mar 2020 16:25:17 +0200 [thread overview]
Message-ID: <83mu88cvqq.fsf@gnu.org> (raw)
In-Reply-To: <874kuhl18k.fsf@gmail.com> (message from Noam Postavsky on Sat, 21 Mar 2020 19:47:07 -0400)
> From: Noam Postavsky <npostavs@gmail.com>
> Cc: michael_heerdegen@web.de, joostkremers@fastmail.fm,
> 40088@debbugs.gnu.org, monnier@iro.umontreal.ca
> Date: Sat, 21 Mar 2020 19:47:07 -0400
>
> The underlying cause is in backtrace_eval_unrewind, which is used to
> temporarily reverse let-bindings (it's called with a positive argument
> to reverse bindings, and then a negative argument to re-apply them) by
> backtrace--locals and backtrace-eval. For the SPECPDL_LET_DEFAULT and
> SPECPDL_LET_LOCAL cases (which occur for let-bindings on buffer-local
> variables), the code calls Fdefault_value and Fbuffer_local_value on the
> symbol.
>
> For symbols which are unbound at top-level, the first (with positive
> argument) call to backtrace_eval_unrewind will set the symbol's value to
> unbound (putting the current value in the specpdl's "old value" slot).
> On the second (with negative argument) call, backtrace_eval_unrewind
> attempts to retrieve the symbol's value with Fdefault_value or
> Fbuffer_local_value, but that raises a void-variable signal. This
> interrupts the restoration of the let-bindings, so any other variables
> more recent on the stack will now have the wrong value.
>
> ielm happens to have some buffer-local variables which are unbound at
> top-level, which is why it can trigger this problem. But any situation
> with void variables with buffer-local let-bindings can also trigger it.
>
> Now, all of the above is true also for Emacs 26 and earlier.
It sounds like a very basic error. How come we never saw it before?
Is it just luck?
> So the effects of this bug are newly significant in Emacs 27. The fact
> that it strikes when the debugger opens, means that it can multiply the
> difficulty of analysing other bugs. And the fix looks quite small and
> safe enough to qualify for emacs-27.
I'm okay with making the change on the emacs-27 branch, but please put
some of the description above in the commit log message, including why
calling default_value etc. avoids the problem (which might not be
obvious, unless one remembers by heart what Fdefault_value does).
Thanks.
next prev parent reply other threads:[~2020-03-22 14:25 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-16 11:40 bug#40088: 27.0.90; Symbol’s value as variable is void: debugger-outer-match-data Joost Kremers
2020-03-17 1:01 ` Michael Heerdegen
2020-03-17 10:41 ` Robert Pluim
2020-03-17 11:06 ` Dmitry Gutov
2020-03-18 0:06 ` Michael Heerdegen
2020-03-18 0:12 ` bug#40088: 27.0.90; Symbol?s " Drew Adams
2020-03-18 1:44 ` Noam Postavsky
2020-03-18 1:49 ` Drew Adams
2020-03-18 22:31 ` Michael Heerdegen
2020-03-18 6:34 ` bug#40088: 27.0.90; Symbol’s " Dmitry Gutov
2020-03-18 22:24 ` Michael Heerdegen
2020-03-18 22:30 ` Dmitry Gutov
2020-03-18 22:46 ` Michael Heerdegen
2020-03-17 11:44 ` Noam Postavsky
2020-03-19 0:04 ` Noam Postavsky
2020-03-19 0:18 ` Stefan Monnier
2020-03-20 8:37 ` Noam Postavsky
2020-03-20 8:56 ` Eli Zaretskii
2020-03-21 23:47 ` Noam Postavsky
2020-03-22 14:25 ` Eli Zaretskii [this message]
2020-03-23 3:17 ` Noam Postavsky
2020-03-23 3:30 ` Eli Zaretskii
2020-03-23 3:40 ` Noam Postavsky
2020-03-23 14:16 ` Eli Zaretskii
2020-03-23 14:34 ` Noam Postavsky
2020-03-23 15:53 ` Joost Kremers
2020-03-20 13:20 ` Stefan Monnier
2020-03-20 14:00 ` Robert Pluim
2020-03-20 14:51 ` Stefan Monnier
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=83mu88cvqq.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=40088@debbugs.gnu.org \
--cc=joostkremers@fastmail.fm \
--cc=michael_heerdegen@web.de \
--cc=monnier@iro.umontreal.ca \
--cc=npostavs@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.