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

Previous Next

Full log

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

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: NiwTinray <niwtrx <at> icloud.com>, 38912 <at> debbugs.gnu.org,
 Daniel Colascione <dancol <at> dancol.org>
Subject: Re: bug#38912: 27.0.60;
 PDumper meets segmentation fault when evil is loaded
Date: Mon, 6 Jan 2020 15:51:57 +0000

On Sun, Jan 5, 2020 at 6:46 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> In my debug build of Emacs 27.0.60 I get an assertion violation while
> dumping, which probably is already a sign of trouble.

I think that's unrelated, but here's some analysis anyway, in case we
want to fix this bug:

Different bytecode objects may be `equal', but have different sxhashes.

(equal #[0 "" [] 0]
       #[0 "" [] 0])
(sxhash #[0 "" [] 0])
(sxhash #[0 "" [] 0])

When such bytecodes are used as keys for a hash table using
hashfn_equal, I believe the result is, fairly obviously, two hash
table entries for equal keys; when the hash table is rehashed, we may
be unlucky enough to retrieve the wrong one, leading to the crash.

That's what cl-generic.el does for the table cl--generic-dispatchers,
which I believe is what you were looking at.

>   #2  0x01326817 in check_hash_table_rehash (table_orig=XIL(0xa000000006288090))
>       at pdumper.c:2684

Can you confirm table_orig is cl--generic-dispatchers?

Again, I doubt this is related to the original bug. That `equal'
behaves weirdly like this is a problem I've mentioned before (when
(equal a b) signals but (equal b a) succeeds), but the consensus then
was not to change it, so it's possible this is only the rehashing
check needing to be more careful.

Previous Next

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