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

Previous Next

Full log

Message #20 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: 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 16:38:48 +0000

On Mon, Jan 6, 2020 at 4:33 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > 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.

I meant something like

p Fsymbol_value(intern("cl--generic-dispatchers"))

in gdb. Will that work on your platform?

> Hash tables don't seem to have names stored
> in them, do they?  (If they did, I'd expect xhashtable to print that
> name.)

They don't have names, no.

> > 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.
>
> If you can suggest how to make that check more careful, please do.

I'd suggest just skipping the entire check for hashfn_equal, at least
on the Emacs 27 branch. On master, I'd prefer to make equal-equality
imply sxhash-equality.

Previous Next

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