[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: |
Fri, 29 May 2020 18:37:42 +0000 |
On Fri, May 29, 2020 at 6:31 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 5/29/20 2:43 AM, Pip Cet wrote:
> > As I said, the code is tricky (i.e. might contain bugs that can only
> > be discovered through extensive testing on 32-bit systems), and it
> > complicates what should be generic functions for the rbtree
> > implementation, so this is probably a 32-bit optimization that is too
> > late because 32-bit systems are no longer that relevant...
>
> At least at first, it may make more sense to keep the red-black trees as-is,
> and
> to look up what appear to be symbol-tagged pointers twice, once as-is (to find
> any kind of object) and once offset by '(char *) lispsym - Lisp_Symbol' (to
> find
> only symbols).
Having had some time to think about this, I agree. I'm certainly not
very confident in that code.
But the main reason is that it's not an optimization in all
circumstances: if you have a very large vector, and a symbol block
aliasing it as symbol offsets goes away, you have to search for other
symbol blocks with that property, which might take a long time.
However, I wonder what you mean by "what appear to be symbol-tagged
pointers"? Surely we need to look up all pointers twice, no matter
what their tag is, since they might be a reference to something inside
the struct Lisp_Symbol.
Of course, on 64-bit machines, this line of code would usually save us
the trouble:
if (start < min_heap_address || start > max_heap_address)
return MEM_NIL;
So that's another reason to leave the code as it is for now.
> Although a bit slower, this won't require any changes to the
> rbtree code so it's cleaner.
> We can then time the optimization you have in mind, to see whether it's worth
> doing.
... or something simpler that might actually work better :-)
- 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, Stefan Monnier, 2020/05/27
- 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, Stefan Monnier, 2020/05/28
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Pip Cet, 2020/05/28
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Stefan Monnier, 2020/05/28
- 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, Paul Eggert, 2020/05/29
- 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, 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, Stefan Monnier, 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, 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, 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, Eli Zaretskii, 2020/05/30
- bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects, Stefan Monnier, 2020/05/30