bug#2099: 23.0.60; `mark_object' with larger nested objects crashes Emacs

[Eli Zaretskii]

> From: Alan J Third <alan@idiocy.org>
> Date: Sun, 10 Jan 2016 22:12:10 +0000
> Cc: Markus Triska <markus.triska@gmx.at>, 2099@debbugs.gnu.org
> 
> > Markus Triska <address@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?