* bug#5662: flet not undone on lisp nesting error
@ 2010-03-01 2:30 Dan Davison
2010-03-05 20:30 ` Stefan Monnier
2016-06-02 1:15 ` Noam Postavsky
0 siblings, 2 replies; 5+ messages in thread
From: Dan Davison @ 2010-03-01 2:30 UTC (permalink / raw)
To: 5662
If I trigger a lisp nesting error with an infinite recursion inside a
let and an flet binding, then the effects of the flet are not undone,
resulting in a change of binding at the top-level.
(defun g () 'g-orig)
(setq a 'a-orig)
(defun h ()
(let ((a 'a-new))
(flet ((g () 'g-new))
(h))))
(h) ;; <-- Lisp nesting exceeds `max-lisp-eval-depth'
(g) ;; g-new !
a ;; a-orig
Dan
If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
`bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/share/emacs/23.1/etc/DEBUG for instructions.
In GNU Emacs 23.1.1 (i486-pc-linux-gnu, GTK+ Version 2.18.3)
of 2009-11-10 on vernadsky, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.10604000
configured using `configure '--build=i486-linux-gnu' '--host=i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.1/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.1/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_GB.UTF-8
value of $XMODIFIERS: nil
locale-coding-system: utf-8-unix
default-enable-multibyte-characters: t
Major mode: Article
Minor modes in effect:
erc-list-mode: t
erc-menu-mode: t
erc-autojoin-mode: t
erc-ring-mode: t
erc-networks-mode: t
erc-pcomplete-mode: t
erc-track-mode: t
erc-track-minor-mode: t
erc-match-mode: t
erc-button-mode: t
erc-fill-mode: t
erc-stamp-mode: t
erc-netsplit-mode: t
erc-irccontrols-mode: t
erc-noncommands-mode: t
erc-move-to-prompt-mode: t
erc-readonly-mode: t
show-paren-mode: t
recentf-mode: t
yas/minor-mode: t
diff-auto-refine-mode: t
shell-dirtrack-mode: t
tooltip-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
global-auto-composition-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up>
<up> <up> <up> <up> <up> <up> <up> <up> <up> <tab>
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up>
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <tab>
C-x C-s <up> <up> <f1> <up> M-g <return> 1 0 0 <return>
<down> <down> <down> <return> <down> <return> <escape>
SPC SPC <up> <down> <prior> <prior> <escape> <up> <return>
<escape> <escape> <down> <return> <escape> <next> <down>
<down> <down> <down> <down> <down> <down> <down> <down>
<down> <down> <down> <down> <down> <down> <down> <down>
<down> <down> <down> <down> <down> <down> <down> <down>
<down> <down> <up> <up> <up> <prior> <prior> <next>
<next> <escape> <down> <down> <f10> <down> <up> <up>
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up>
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up>
<up> <up> <up> <up> <down> <down> <down> <down> <down>
<down> <down> <down> <down> <down> <down> <down> <down>
<down> <down> <down> <down> <down> <down> <next> <prior>
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up>
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up>
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up>
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up>
<up> <up> <up> <up> <up> <up> <up> <up> <down> <down>
<down> <down> <down> <down> <down> <down> <down> <up>
<up> <up> <up> <up> <up> <down> <return> <escape> <up>
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up>
<up> <up> <up> <prior> <prior> <down> <down> <escape>
<escape> <next> <up> <escape> <escape> <next> <prior>
<prior> <escape> <up> <down> q <return> 2 0 0 <return>
C-s f l e t C-s C-s <down> <up> <up> <return> <escape>
<down> C-SPC M-> M-w M-x r e p o r t <tab> b u <tab>
<return>
Recent messages:
End of message
nnimap: Setting marks in INBOX...done
No more unread newsgroups
Retrieving newsgroup: INBOX...
nnimap: Updating info for INBOX...done
Fetching headers for INBOX...done
Generating summary...done
Mark saved where search started
Mark set
Saved text from "If I trigger a lisp nesting error with a"
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#5662: flet not undone on lisp nesting error
2010-03-01 2:30 bug#5662: flet not undone on lisp nesting error Dan Davison
@ 2010-03-05 20:30 ` Stefan Monnier
2014-11-11 2:16 ` Jinseop Kim
2016-06-02 1:15 ` Noam Postavsky
1 sibling, 1 reply; 5+ messages in thread
From: Stefan Monnier @ 2010-03-05 20:30 UTC (permalink / raw)
To: Dan Davison; +Cc: 5662
> If I trigger a lisp nesting error with an infinite recursion inside a
> let and an flet binding, then the effects of the flet are not undone,
> resulting in a change of binding at the top-level.
> (defun g () 'g-orig)
> (setq a 'a-orig)
> (defun h ()
> (let ((a 'a-new))
> (flet ((g () 'g-new))
> (h))))
> (h) ;; <-- Lisp nesting exceeds `max-lisp-eval-depth'
> (g) ;; g-new !
> a ;; a-orig
I can indeed reproduce it. I'm not sure yet what's going on, but it
might be due to the "Lisp nesting exceeds `max-lisp-eval-depth'" error
happening in the unwind-protect code (i.e. while undoing the `g'
binding). The explanation can't be quite so simple, but my gut feeling
tells me it's got to do with it.
Stefan
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#5662: flet not undone on lisp nesting error
2010-03-05 20:30 ` Stefan Monnier
@ 2014-11-11 2:16 ` Jinseop Kim
2014-11-11 15:50 ` Stefan Monnier
0 siblings, 1 reply; 5+ messages in thread
From: Jinseop Kim @ 2014-11-11 2:16 UTC (permalink / raw)
To: 5662; +Cc: Dan Davison
You can see the bug of 'unwind-protect' using the following code.
We must see the message “finally”, but are not output.
```elisp
(defun endless-recursive ()
(endless-recursive))
(unwind-protect
(endless-recursive) ;; body
(message "finally”)) ;; unwind-forms
```
The `unwind-protect’ will call the `eval_sub’ function.
And, the `eval_sub’ function check whether the infinite recursion as following code.
```c
/* ./src/eval.c:2086: */
if (++lisp_eval_depth > max_lisp_eval_depth)
{
if (max_lisp_eval_depth < 100)
max_lisp_eval_depth = 100;
if (lisp_eval_depth > max_lisp_eval_depth)
error ("Lisp nesting exceeds `max-lisp-eval-depth'");
}
```
The cause of problem is that `unwind-forms’ will call the `eval_sub’ function.
Of course, the `eval_sub’ function check for infinite recursion.
Consequently, the `unwind-protect’ wouldn't evaluate.
You must be noted step 7~10.
Problem's steps:
1. eval.c:1208:Funwind_protect: record_unwind_protect (unwind_body, XCDR (args));
2. eval.c:1209:Funwind_protect: val = eval_sub (XCAR (args));
3. eval.c:2090:eval_sub: if (lisp_eval_depth > max_lisp_eval_depth) error ("Lisp nesting exceeds `max-lisp-eval-depth'”);
4. eval.c:1582:xsignal: Fsignal (error_symbol, data);
5. eval.c:1558:Fsignal: unwind_to_catch (h, unwind_data);
6. eval.c:1161:unwind_to_catch: unbind_to (handlerlist->pdlcount, Qnil);
7. eval.c:3305:unbind_to: unwind_body // specpdl_ptr->unwind_ptr.func (specpdl_ptr->unwind_ptr.arg);
8. eval.c:476:unwind_body: Fprogn (body);
9. eval.c:462:Fprogn: val = eval_sub (XCAR (body));
10. eval.c:2090:eval_sub: if (lisp_eval_depth > max_lisp_eval_depth) error ("Lisp nesting exceeds `max-lisp-eval-depth’”)
You can avoid this problem using `ignore-errors’ macro.
(eval.c:1175:unwind_to_catch: lisp_eval_depth = catch->lisp_eval_depth;)
```elisp
(defun endless-recursive ()
(endless-recursive))
(unwind-protect
(ignore-errors (endless-recursive))
(message "finally"))
```
> On Mar 6, 2010, at 5:30 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>> If I trigger a lisp nesting error with an infinite recursion inside a
>> let and an flet binding, then the effects of the flet are not undone,
>> resulting in a change of binding at the top-level.
>
>> (defun g () 'g-orig)
>> (setq a 'a-orig)
>
>> (defun h ()
>> (let ((a 'a-new))
>> (flet ((g () 'g-new))
>> (h))))
>> (h) ;; <-- Lisp nesting exceeds `max-lisp-eval-depth'
>> (g) ;; g-new !
>> a ;; a-orig
>
> I can indeed reproduce it. I'm not sure yet what's going on, but it
> might be due to the "Lisp nesting exceeds `max-lisp-eval-depth'" error
> happening in the unwind-protect code (i.e. while undoing the `g'
> binding). The explanation can't be quite so simple, but my gut feeling
> tells me it's got to do with it.
>
>
> Stefan
>
>
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#5662: flet not undone on lisp nesting error
2014-11-11 2:16 ` Jinseop Kim
@ 2014-11-11 15:50 ` Stefan Monnier
0 siblings, 0 replies; 5+ messages in thread
From: Stefan Monnier @ 2014-11-11 15:50 UTC (permalink / raw)
To: Jinseop Kim; +Cc: Dan Davison, 5662
> The cause of problem is that `unwind-forms’ will call the `eval_sub’
> function. Of course, the `eval_sub’ function check for infinite
> recursion. Consequently, the `unwind-protect’ wouldn't evaluate.
Thanks for digging into it. Indeed, I think I see it now: in
`unbind_to' we run the unwind_forms without updating lisp_eval_depth, so
they're run with the lisp_eval_depth of the place where the signal
was thrown, so if the signal was thrown because lisp_eval_depth >
max_lisp_eval_depth, then the unwind forms will all fail by signaling
error ("Lisp nesting exceeds `max-lisp-eval-depth'").
This said, at the time we run those unwind forms, the C stack is still
at the same "very deep" state as when the error was signaled, so the
lisp_eval_depth value is not completely wrong (more specifically, it
would be unwise in general to simply set it to the value corresponding
to the target of the longjmp, even though in your particular case you
could argue that it would be right).
So maybe the best solution would be to temporarily increase
max-lisp-eval-depth like we do for call_debugger. Not sure how best to
do that, since the way it's done in call_debugger could have too high
a performance cost (it's not a problem for call_debugger since that's
an exceptional situation).
Stefan
> You must be noted step 7~10.
> Problem's steps:
> 1. eval.c:1208:Funwind_protect: record_unwind_protect (unwind_body, XCDR (args));
> 2. eval.c:1209:Funwind_protect: val = eval_sub (XCAR (args));
> 3. eval.c:2090:eval_sub: if (lisp_eval_depth > max_lisp_eval_depth) error ("Lisp nesting exceeds `max-lisp-eval-depth'”);
> 4. eval.c:1582:xsignal: Fsignal (error_symbol, data);
> 5. eval.c:1558:Fsignal: unwind_to_catch (h, unwind_data);
> 6. eval.c:1161:unwind_to_catch: unbind_to (handlerlist->pdlcount, Qnil);
> 7. eval.c:3305:unbind_to: unwind_body // specpdl_ptr->unwind_ptr.func (specpdl_ptr->unwind_ptr.arg);
> 8. eval.c:476:unwind_body: Fprogn (body);
> 9. eval.c:462:Fprogn: val = eval_sub (XCAR (body));
> 10. eval.c:2090:eval_sub: if (lisp_eval_depth > max_lisp_eval_depth) error ("Lisp nesting exceeds `max-lisp-eval-depth’”)
> You can avoid this problem using `ignore-errors’ macro.
> (eval.c:1175:unwind_to_catch: lisp_eval_depth = catch->lisp_eval_depth;)
> ```elisp
> (defun endless-recursive ()
> (endless-recursive))
> (unwind-protect
> (ignore-errors (endless-recursive))
> (message "finally"))
> ```
>> On Mar 6, 2010, at 5:30 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>
>>> If I trigger a lisp nesting error with an infinite recursion inside a
>>> let and an flet binding, then the effects of the flet are not undone,
>>> resulting in a change of binding at the top-level.
>>
>>> (defun g () 'g-orig)
>>> (setq a 'a-orig)
>>
>>> (defun h ()
>>> (let ((a 'a-new))
>>> (flet ((g () 'g-new))
>>> (h))))
>>> (h) ;; <-- Lisp nesting exceeds `max-lisp-eval-depth'
>>> (g) ;; g-new !
>>> a ;; a-orig
>>
>> I can indeed reproduce it. I'm not sure yet what's going on, but it
>> might be due to the "Lisp nesting exceeds `max-lisp-eval-depth'" error
>> happening in the unwind-protect code (i.e. while undoing the `g'
>> binding). The explanation can't be quite so simple, but my gut feeling
>> tells me it's got to do with it.
>>
>>
>> Stefan
>>
>>
>>
>>
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#5662: flet not undone on lisp nesting error
2010-03-01 2:30 bug#5662: flet not undone on lisp nesting error Dan Davison
2010-03-05 20:30 ` Stefan Monnier
@ 2016-06-02 1:15 ` Noam Postavsky
1 sibling, 0 replies; 5+ messages in thread
From: Noam Postavsky @ 2016-06-02 1:15 UTC (permalink / raw)
To: 5662
found 5662 23.4
found 5662 24.3
found 5662 24.5
fixed 5662 25.0.94
close 5662
quit
Seems to have been fixed in Emacs 25. I could reproduce in several
earlier versions (had to add a (require 'cl) to demo code).
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-06-02 1:15 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-01 2:30 bug#5662: flet not undone on lisp nesting error Dan Davison
2010-03-05 20:30 ` Stefan Monnier
2014-11-11 2:16 ` Jinseop Kim
2014-11-11 15:50 ` Stefan Monnier
2016-06-02 1:15 ` Noam Postavsky
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).