[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" <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?
- bug#34655: 26.1.92; Segfault in module with --module-assertions, (continued)
- bug#34655: 26.1.92; Segfault in module with --module-assertions, Philipp Stephani, 2019/03/21
- bug#34655: 26.1.92; Segfault in module with --module-assertions, Eli Zaretskii, 2019/03/21
- bug#34655: 26.1.92; Segfault in module with --module-assertions, Philipp Stephani, 2019/03/21
- bug#34655: 26.1.92; Segfault in module with --module-assertions, Eli Zaretskii, 2019/03/21
- bug#34655: 26.1.92; Segfault in module with --module-assertions, Philipp Stephani, 2019/03/21
- bug#34655: 26.1.92; Segfault in module with --module-assertions, Eli Zaretskii, 2019/03/21
- bug#34655: 26.1.92; Segfault in module with --module-assertions, Philipp Stephani, 2019/03/21
- bug#34655: 26.1.92; Segfault in module with --module-assertions, Eli Zaretskii, 2019/03/21
- bug#34655: 26.1.92; Segfault in module with --module-assertions, Philipp Stephani, 2019/03/21
- bug#34655: 26.1.92; Segfault in module with --module-assertions, Daniel Colascione, 2019/03/21
- bug#34655: 26.1.92; Segfault in module with --module-assertions,
Eli Zaretskii <=
- bug#34655: 26.1.92; Segfault in module with --module-assertions, Eli Zaretskii, 2019/03/21
- bug#34655: 26.1.92; Segfault in module with --module-assertions, Basil L. Contovounesios, 2019/03/21
- bug#34655: 26.1.92; Segfault in module with --module-assertions, Stefan Monnier, 2019/03/21
- bug#34655: 26.1.92; Segfault in module with --module-assertions, Eli Zaretskii, 2019/03/22
- bug#34655: 26.1.92; Segfault in module with --module-assertions, Philipp Stephani, 2019/03/21
- bug#34655: 26.1.92; Segfault in module with --module-assertions, Eli Zaretskii, 2019/03/21
- bug#34655: 26.1.92; Segfault in module with --module-assertions, Basil L. Contovounesios, 2019/03/21
- bug#34655: 26.1.92; Segfault in module with --module-assertions, Eli Zaretskii, 2019/03/22