GNU bug report logs - #2099
stack overflow in GC when creating large nested object

Previous Next

Package: emacs;

Reported by: Markus Triska <markus.triska <at> gmx.at>

Date: Wed, 28 Jan 2009 23:15:02 UTC

Severity: wishlist

Tags: confirmed

Merged with 31362

Found in version 24.5

Done: Mattias EngdegÄrd <mattiase <at> acm.org>

Bug is archived. No further changes may be made.

Full log


Message #25 received at 2099 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan J Third <alan <at> idiocy.org>
Cc: larsi <at> gnus.org, 2099 <at> debbugs.gnu.org, markus.triska <at> gmx.at
Subject: Re: bug#2099: 23.0.60;
 `mark_object' with larger nested objects crashes Emacs
Date: Mon, 11 Jan 2016 17:11:44 +0200
> From: Alan J Third <alan <at> idiocy.org>
> Date: Sun, 10 Jan 2016 22:12:10 +0000
> Cc: Markus Triska <markus.triska <at> gmx.at>, 2099 <at> debbugs.gnu.org
> 
> > Markus Triska <address <at> hidden> writes:
> >
> >> When you do:
> >>
> >>    $ emacs -Q --eval "(let (v) (while t (setq v (cons v v))))"
> >>
> >> then Emacs crashes with:
> >>
> >>    Program received signal EXC_BAD_ACCESS, Could not access memory.
> >>    Reason: KERN_INVALID_ADDRESS at address: 0xbf7ffffc
> >>    0x0013bc1a in mark_object (arg=40166541) at alloc.c:5372
> >>    (gdb) bt
> >>    #0  0x0013bc1a in mark_object (arg=40166541) at alloc.c:5372
> >
> > I can confirm that the crash is still present in Emacs 24:
> 
> And Emacs 25:
> 
> Fatal error 11: Segmentation fault

Of course: this is expected.

I admit I don't really understand what is the purpose of this bug
report; perhaps the OP could clarify.

Here's my take on this:

  . What happens is clear: stack overflow during GC.  Since the stack
    space is always limited, one can always overflow it by
    deliberately consing larger and larger objects.

  . When stack overflow happens during GC, Emacs commits suicide,
    because such fatal errors are not recoverable with the current
    code.

  . Making GC non-recursive is a large job, that will most probably
    require significant changes in GC as a whole, not just in the
    recursive mark step.  If someone wants to work on that, they
    surely don't need this bug as an inspiration.

IOW, this is a known limitation of the current GC implementation.  So
I think we should mark this bug "wishlist" (or maybe even "wontfix"),
and leave it at that.

Any objections/comments/suggestions?




This bug report was last modified 3 years and 49 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.