bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects


From: Pip Cet
Subject: bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects
Date: Thu, 28 May 2020 08:11:42 +0000

On Thu, May 28, 2020 at 7:47 AM Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 5/27/20 11:31 PM, Pip Cet wrote:
> > I hope you're right, in that compilers will support GC better before
> > they move on to clever optimizations that break it :-)
>
> After looking into it, I decided it wasn't worth the hassle of treating 
> pointers
> just past the end of a Lisp object as pointing into the object. Although such
> pointers can exist, I can't think of a realistic-with-today's-compilers 
> scenario
> at the machine level where (1) a pointer like that will exist, (2) no pointers
> into the middle or start of the object will exist, and (3) the object might be
> accessed later. In contrast we have seen scenarios with pointers into the 
> middle
> of Lisp objects.

Okay. I was about to write that I'd concluded the same thing, after
failing to come up with an example other than that hypothetical
Freverse implementation.

> With that in mind, attached is a proposed patch to master that I hope deals 
> with
> some of the more-serious problems mentioned so far in this thread, in 
> particular
> the problem with Lisp_Object representations of symbols being split into two
> registers in a --with-wide-int build. I haven't tested this as much as I'd 
> like,
> but I need to turn my attention to sleep and work and so this is a good place 
> to
> broadcast a checkpoint.

Thanks! Looks great generally, though I confess I haven't checked what
would happen in a (hypothetical?) !USE_LSB_TAG 64-bit case.

+      if (!symbol_only && live_float_p (m, p))
+        obj = make_lisp_ptr (cp - (uintptr_t) cp % GCALIGNMENT, Lisp_Float);
       break;

I'm not sure about this code, though, it assumes GCALIGNMENT == sizeof
Lisp_Float.

> PS. Thanks for helping bring this problem to our attention; it's been fun to
> look into it.

I agree. I'll certainly continue looking for bugs and working on
Emacs, but at this point I'm unsure it's worth it to actually share
such work with anyone. But that doesn't really belong here.





reply via email to

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