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

[Eli Zaretskii]

> From: markus.triska@gmx.at
> Cc: alan@idiocy.org, 2099@debbugs.gnu.org, larsi@gnus.org
> Date: Mon, 11 Jan 2016 20:57:49 +0100
> 
> > Sorry, I don't understand: what testing? Can you describe the
> > real-life use case behind this bug report? The recipe as shown looks
> > like a deliberate way to cause Emacs to overflow its stack; surely,
> > that's not what you intended to test?
> 
> That's not what I intended to test: Emacs crashing on such datastructures
> prevents more serious automatic tests that can, among other data, also
> create such structures.

I'm asking to describe the data structures that you intended to test,
and their purpose.  The recipe that you posted when you filed the bug
conses an infinitely large object in an infinite loop.  Can you please
tell what is the purpose of creating such a data structure in this
way?  It's clear that at some point Emacs will run out of memory, and
it is also clear that at some other point it will GC.  So what is
being tested by such a data structure, given that these outcomes are
known in advance?

> So far, this shortcoming has prevented my working further on such
> tests.

Knowing more about those tests might help us become more motivated to
work on the problems that interfere with your testing, or suggest how
to work around them.

> I find it hard to believe that a way to crash Emacs is somehow *not*
> considered a bug.

There could be many ways to overcome these problems, some of them
easier than others.  It all depends on what problems get in your way.

For example, there could be a way of letting Emacs run out of heap
memory without triggering GC -- would that help you continue with your
testing?  I don't know, maybe you could tell.

IOW, if there are practical issues for which you'd like to have a
solution or a workaround, so that you could continue with your
testing, we could try helping you on that way.  I'm sure you agree
that leaving the bug without any action will not help you make any
progress with your project.  Please help us help you in any practical
way that's possible, by telling more about the specific aspects of
Emacs you'd like to test.

> If that is the case, I agree with what Glenn recently said: Just
> deal with this report in any way you wish.

Relax, no one said this isn't a bug, so this is uncalled for.  I'm
just trying to understand what is being tested here.  I couldn't
understand that from the recipe you posted, because that recipe has an
outcome that's known in advance.