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

Previous Next

Full log

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

From: "Daniel Colascione" <dancol <at> dancol.org>
To: "Eli Zaretskii" <eliz <at> gnu.org>
Cc: niwtrx <at> icloud.com, 38912 <at> debbugs.gnu.org, dancol <at> dancol.org,
 Pip Cet <pipcet <at> gmail.com>
Subject: Re: bug#38912: 27.0.60; PDumper meets segmentation fault when evil
 is loaded
Date: Mon, 6 Jan 2020 09:01:24 -0800

>> From: Pip Cet <pipcet <at> gmail.com>
>> Date: Mon, 6 Jan 2020 15:51:57 +0000
>> Cc: NiwTinray <niwtrx <at> icloud.com>, Daniel Colascione
>> <dancol <at> dancol.org>, 38912 <at> debbugs.gnu.org
>>
>> >   #2  0x01326817 in check_hash_table_rehash
>> (table_orig=XIL(0xa000000006288090))
>> >       at pdumper.c:2684
>>
>> Can you confirm table_orig is cl--generic-dispatchers?
>
> I don't think I know how.  Hash tables don't seem to have names stored
> in them, do they?  (If they did, I'd expect xhashtable to print that
> name.)
>
>> 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.

This consensus is wrong. We need to make equality imply sxhash equality or
very odd things (like this) will happen. C++ and Java both require this
relationship between hash code equality and object equality, and we should
too. Can we just fix the bytecode sxhash bug?

Previous Next

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