[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: bug#34655: 26.1.92; Segfault in module with --module-assertions
Date: Fri, 22 Mar 2019 11:17:56 +0300

> Date: Thu, 21 Mar 2019 13:48:28 -0700
> From: "Daniel Colascione" <address@hidden>
> Cc: "Eli Zaretskii" <address@hidden>,
>  "Stefan Monnier" <address@hidden>,
>  "Basil L. Contovounesios" <address@hidden>,
>  address@hidden,
>  "Daniel Colascione" <address@hidden>
> > 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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]