GNU bug report logs - #38912
27.0.60; PDumper meets segmentation fault when evil is loaded

Previous Next

Full log

Message #88 received at 38912 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: niwtrx <at> icloud.com, 38912 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Daniel Colascione <dancol <at> dancol.org>
Subject: Re: bug#38912: 27.0.60;
 PDumper meets segmentation fault when evil is loaded
Date: Tue, 7 Jan 2020 19:31:10 +0000

On Mon, Jan 6, 2020 at 6:13 PM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
> The problem is simply that `sxhash` doesn't use the same "rules" about
> which objects are compared by identity and which objects are compared
> by contents.

I agree.

> so the problem doesn't affect only byte-compiled objects but also
> overlays, markers, windowconfigs, chartables, and fonts, AFAICT.

True, but then, those don't make much sense as hash keys in an
equal-based hash table. I don't think bytecode objects make sense as
hash keys in an equal-based hash table, either: two bytecode objects
can be `equal` yet be non-equivalent, even though it's somewhat
unlikely to occur in practice.

> The fix should be to make `sxhash` follow the same rules as `internal_equal`.

I think the two should largely follow the same rules, because all of
those objects should be equal iff they're eq. Hashing a marker based
on its position, for example, makes little sense: when the marker
moves, the hash value would change. Bytecode objects could be compared
based on their string representation, I guess, and maybe should be
hash-consed based on that (deduplicating identical bytecode objects
used as constants in other bytecode objects appears to save quite a
bit of space), once they're made immutable.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.