[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: |
Sat, 30 May 2020 13:29:33 +0000 |
On Sat, May 30, 2020 at 11:31 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Sat, 30 May 2020 11:06:52 +0000
> > Cc: eggert@cs.ucla.edu, 41321@debbugs.gnu.org,
> > Stefan Monnier <monnier@iro.umontreal.ca>
> >
> > > I understand that part, but my question was why, even before the
> > > change in max_align_t, did we start requiring 8-byte alignment on
> > > systems where that is not automatically guaranteed?
> >
> > I don't know. As I said, I think that was always buggy on pdumper
> > systems, though the bug was very subtle. My guess is it predates
> > pdumper, at which time it was a valid optimization.
>
> How is pdumper involved here?
See the pdumper issue I described above. I can't imagine this being a
significant bug, because it needs the sole surviving reference to a
pdumper object to be on the stack, while simultaneously being the key
in a weak-key hash table cell...
> > > So this alignment requirement is only due to pthreads being used?
> >
> > I'm not sure what you're asking. Obviously there are systems on which
> > unaligned accesses will fault or be very slow indeed, so we need to
> > make sure, say, pure space allocations are aligned somehow. That
> > requires a LISP_ALIGNMENT of 8. Everything beyond that is only for
> > performance, pthreads, and SIMD types.
>
> If the system guarantees 4-byte alignment from malloc (and/or a
> similar alignment of the runtime C stack), then using that doesn't
> trigger problems related to unaligned accesses, right? So let me
> rephrase: why isn't 4-byte alignment "good enough" for us on systems
> where malloc and the runtime stack are guaranteed to be thus aligned?
(The runtime stack isn't relevant, as far as I can tell, since we walk
that in 4-byte steps on such systems anyway.)
You're correct that on such a system, we could get away with a
LISP_ALIGNMENT of 4, but a LISP_ALIGNMENT of 8 wouldn't hurt either.
> > > If
> > > the two 32-bit parts of the object are non-contiguous, will we be able
> > > to recognize such an object, and will we be able to mark it correctly,
> > > and if so, how? IOW, don't we need the upper 32-bit (which encodes
> > > the object type) for the purposes of marking it?
> >
> > For everything but symbols, we don't, mark_maybe_pointer called on the
> > low 32 bits suffices. For symbols, mark_maybe_pointer needs to be
> > changed to also check the pointer at <low 32-bit word> + &lispsym.
>
> Right, that's what I thought. So this issue also has to be fixed on
> emacs-27 in order for us to provide a stable Emacs 27.
I'm surprised, but glad that you think so. Patch for emacs-27 attached.
0001-Be-more-aggressive-in-marking-objects-during-GC-bug-.patch
Description: Text Data
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, (continued)
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Eli Zaretskii, 2020/05/28
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Paul Eggert, 2020/05/28
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Eli Zaretskii, 2020/05/29
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Paul Eggert, 2020/05/29
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/29
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Eli Zaretskii, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Eli Zaretskii, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Eli Zaretskii, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects,
Pip Cet <=
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Eli Zaretskii, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Eli Zaretskii, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Paul Eggert, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Eli Zaretskii, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Paul Eggert, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Paul Eggert, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/30