bug#34655: 26.1.92; Segfault in module with --module-assertions

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Thu, 21 Mar 2019 21:26:25 +0100
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, "Basil L. Contovounesios" 
> <contovob@tcd.ie>, 34655@debbugs.gnu.org, 
>       Daniel Colascione <dancol@dancol.org>
> 
> > I also prefer fixing bugs (which is why I spent several hours looking
> > into Basil's crash, when no one else was replying to that bug report),
> > but this is a community project, so we should discuss first and act
> > later.  Especially when controversial issues are involved.
> 
> Well, as you can see, these discussions seem to lead nowhere, and both
> bug#34655 and bug#31238 remain unfixed.

We have been talking about this just a few minutes, so please don't
exaggerate.  And bug#34655 could be fixed days ago, it isn't yet
because I wanted to hear your opinion, and you asked me to hold off
the changes.

> > > > Why do you think x isn't on the stack in this case?
> > >
> > > Because the compiler reused the stack slot for something else?
> >
> > How can it?  You are using the same pointer later.
> 
> Assume I don't use x later, and only y is on the stack during GC.

If you don't use x, it can be GC'ed.

> >  Garbage collection
> > cannot happen unless you call an Emacs function, such as Ffuncall.
> > Calling a function means that even if the pointer to a Lisp object was
> > in a register, it will be put on the stack when calling Emacs.
> 
> No matter whether y here is in a register or on the stack, it's not a
> Lisp_Value, so the GC can't find it.

But x is.  And there's the original Lisp object too, somewhere on the
stack.

> > > Because the module is written in a language that doesn't use the stack
> > > in a way that the garbage collector expects?
> >
> > Which language is that, and how can it use the emacs-module machinery?
> 
> Go, for example. It uses green threads with its own stack management
> and calling conventions. The GC couldn't ever find such a stack.

So you are saying that Emacs modules cannot be written in Go?

> > > > Moreover, emacs_value is actually a pointer to a Lisp object, so this
> > > > object is also somewhere on the stack, right?
> >
> > No answer?
> 
> An emacs_value in the current implementation *is* a Lisp_Object cast
> to emacs_value.

Under module-assertions, it's a pointer to a (copy of a) Lisp object.

> > If worse comes to worst, we can request module writers to adhere to
> > the same discipline.  We already request them to do/not to do quite a
> > few extraordinary things.
> 
> No we can't. Modules can contain arbitrary code and call arbitrary
> libraries, which we can't ever control. We need to work with
> everything that provides a C-compatible interface.

Emacs modules are written to work with Emacs, so surely we can request
them to observe certain rules, especially if they don't want to crash
Emacs.