* Re: [Emacs-diffs] trunk r117741: Handle C stack overflow caused by too nested Lisp evaluation.
[not found] <E1XMAE8-00085O-Du@vcs.savannah.gnu.org>
@ 2014-08-26 18:37 ` Stefan Monnier
2014-08-27 3:17 ` Dmitry Antipov
0 siblings, 1 reply; 3+ messages in thread
From: Stefan Monnier @ 2014-08-26 18:37 UTC (permalink / raw
To: Dmitry Antipov; +Cc: emacs-devel
> + DEFVAR_LISP ("top-level-message", Vtop_level_message,
> + doc: /* Message displayed by `normal-top-level'. */);
Why does this need to be exported to Elisp?
> + /* Hard GC error may lead to stack overflow caused by
> + too nested calls to mark_object. No way to survive. */
I don't see why there's no way to survive. Isn't it safe to interrupt
GC within the mark phase and re-run it?
Stefan
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Emacs-diffs] trunk r117741: Handle C stack overflow caused by too nested Lisp evaluation.
2014-08-26 18:37 ` [Emacs-diffs] trunk r117741: Handle C stack overflow caused by too nested Lisp evaluation Stefan Monnier
@ 2014-08-27 3:17 ` Dmitry Antipov
2014-08-27 5:04 ` Stefan Monnier
0 siblings, 1 reply; 3+ messages in thread
From: Dmitry Antipov @ 2014-08-27 3:17 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
On 08/26/2014 10:37 PM, Stefan Monnier wrote:
>> + DEFVAR_LISP ("top-level-message", Vtop_level_message,
>> + doc: /* Message displayed by `normal-top-level'. */);
>
> Why does this need to be exported to Elisp?
This is just to allow 'normal-top-level' to display an appropriate message.
>> + /* Hard GC error may lead to stack overflow caused by
>> + too nested calls to mark_object. No way to survive. */
>
> I don't see why there's no way to survive. Isn't it safe to interrupt
> GC within the mark phase and re-run it?
Maybe (at least, it requires some more work). But if we get SIGSEGV in GC,
most likely we have 1) too deep data structures or 2) fatal error,
probably invalid pointer. Since I don't see a way to recover in either
case, I don't see how restarting GC can help.
Dmitry
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Emacs-diffs] trunk r117741: Handle C stack overflow caused by too nested Lisp evaluation.
2014-08-27 3:17 ` Dmitry Antipov
@ 2014-08-27 5:04 ` Stefan Monnier
0 siblings, 0 replies; 3+ messages in thread
From: Stefan Monnier @ 2014-08-27 5:04 UTC (permalink / raw
To: Dmitry Antipov; +Cc: emacs-devel
>>> + DEFVAR_LISP ("top-level-message", Vtop_level_message,
>>> + doc: /* Message displayed by `normal-top-level'. */);
>> Why does this need to be exported to Elisp?
> This is just to allow 'normal-top-level' to display an appropriate message.
Then please name it "internal--top-level-message" or somesuch.
>>> + /* Hard GC error may lead to stack overflow caused by
>>> + too nested calls to mark_object. No way to survive. */
>> I don't see why there's no way to survive. Isn't it safe to interrupt
>> GC within the mark phase and re-run it?
> Maybe (at least, it requires some more work). But if we get SIGSEGV in GC,
> most likely we have 1) too deep data structures or 2) fatal error,
> probably invalid pointer. Since I don't see a way to recover in either
> case, I don't see how restarting GC can help.
Right, we should just abort.
Stefan
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-08-27 5:04 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <E1XMAE8-00085O-Du@vcs.savannah.gnu.org>
2014-08-26 18:37 ` [Emacs-diffs] trunk r117741: Handle C stack overflow caused by too nested Lisp evaluation Stefan Monnier
2014-08-27 3:17 ` Dmitry Antipov
2014-08-27 5:04 ` Stefan Monnier
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.