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 20:37:24 +0100
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, "Basil L. Contovounesios" 
> <contovob@tcd.ie>, 34655@debbugs.gnu.org
> 
> Let's go back to the known good state first, and then discuss how to
> go from there.

I don't see why that is better than discuss first and then go to where
we decide to go.  It's not like Emacs 27 will be released any time
soon, so there's no rush.

> We can't get stack marking to work, even theoretically.
> 
> A module is free to do
> 
> emacs_value x = ...;
> uintptr_t y = ((uintrptr_t) x) ^ 0x123456u;
> (garbage-collect)
> emacs_value z = (emacs_value) (y ^ 0x123456u);
> ... use z ...
> 
> During the garbage collection, x isn't on the stack anywhere

Why do you think x isn't on the stack in this case?

Moreover, emacs_value is actually a pointer to a Lisp object, so this
object is also somewhere on the stack, right?

> emacs_value x = ...;
> emacs_value *y = malloc (sizeof emacs_value);
> *y = x;
> ... stop using x...
> (garbage-collect)
> ...use *y ...
> 
> Again, during garbage collection x is no longer on the stack.

Why do you think it isn't on the stack?

> We can only use stack scanning in Emacs because we control the Emacs
> source code

Actually, we do nothing special about stack-based values in our
sources, except avoiding undefined behavior.

> > OK, but I think Stefan's opinion is not less important.
> 
> I value his opinion, but again: let's make the thing work first, and
> then discuss options.

Fixing one bug doesn't necessarily mean things now "work"; there's
always one more bug.