bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded

[Pip Cet <pipcet@gmail.com>]

On Mon, Jan 6, 2020 at 6:13 PM Stefan Monnier <monnier@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.