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

[Eli Zaretskii]

> Date: Thu, 21 Mar 2019 13:48:28 -0700
> From: "Daniel Colascione" <dancol@dancol.org>
> Cc: "Eli Zaretskii" <eliz@gnu.org>,
>  "Stefan Monnier" <monnier@iro.umontreal.ca>,
>  "Basil L. Contovounesios" <contovob@tcd.ie>,
>  34655@debbugs.gnu.org,
>  "Daniel Colascione" <dancol@dancol.org>
> 
> > 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.
> 
> Modules can contain arbitrary code, but they don't have to do arbitrary
> things with that code. Right now, the contract between modules and Emacs
> is something like "any value that, I, Emacs, can't find on an
> Emacs-findable thread is fair game for memory reclaimation." In practice,
> that works okay most of the time, but if we have to deal with environments
> that can't guarantee that Emacs values remain on the C stack, we can
> extend the contract with something like "I, module, am handing you, Emacs,
> an array of emacs_values, and in addition to my stack, you should check
> this array before considering a value dead" --- that is, we could just
> provide a way for a module to associate a bunch of additional GC roots
> with a given context. Then something like Go could stick any temporary
> Emacs values in this array.
> 
> Or we could just have these environments create permanent references.

OK, thanks.

What are your opinions regarding usability of stack marking for
emacs_value variables used by modules?