GNU bug report logs - #36447
27.0.50; New "Unknown keyword" errors

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, npostavs <at> gmail.com, 36447 <at> debbugs.gnu.org
Subject: bug#36447: 27.0.50; New "Unknown keyword" errors
Date: Fri, 5 Jul 2019 08:36:57 +0000

On Fri, Jul 5, 2019 at 8:25 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Pip Cet <pipcet <at> gmail.com>
> > Date: Fri, 5 Jul 2019 08:12:07 +0000
> > Cc: michael_heerdegen <at> web.de, npostavs <at> gmail.com, 36447 <at> debbugs.gnu.org
> >
> > On Fri, Jul 5, 2019 at 7:50 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > > rwatch -l *(long *)&XHASH_TABLE(obj)->index
> > > > watch -l *(long *)XHASH_TABLE(obj)->index
> > >
> > > I think this is the same as
> > >
> > >   awatch -l *(long *)XHASH_TABLE(obj)->index
> >
> > Thanks for checking! What I actually meant was
> > awatch -l *(long *)&XHASH_TABLE(obj)->index
>
> But then why do you need the rwatch as well?  awatch breaks both on
> read accesses and on write accesses.

I don't! Just the awatch is fine, thanks again for pointing it out.
It's just that the argument needs a & or we're watching the wrong bit
of memory.


> > With revision 44f199648b0c986a0ac7608f4e9d803c619ae2d6, I can
> > reproduce this problem locally, and I can confirm it's as I thought:
> >
> > y-or-no-p and custom-handle-keyword both generate 7-element hash
> > tables. They share a ->next vector. Both try to rehash the hash table,
> > and since there are non-builtin symbols in there, the new hash
> > collision chains should differ, but can't, since they share a vector.

I've since confirmed that this gdb session does not exhibit the bug:

b hash_table_rehash
Breakpoint 3 at 0x66bbb6: file fns.c, line 4224.
(gdb) command 3
Type commands for breakpoint(s) 3, one per line.
End with a line saying just "end".
>p h->next = Fcopy_sequence(h->next)
>c
>end
(gdb) r

(this is on a CFLAGS="-O0 -g3 -ggdb" build, on GNU/Linux)

> > I don't think we can sensibly add tests for this bug, but the fix I
> > posted earlier still seems valid to me.
>
> Sorry, I'm not tracking this part of the discussion, as it lost me
> long ago.

What's the best way of getting this fixed? Current master is pretty
unusable due to this bug, once you call `y-or-n-p' and
`custom-handle-keyword', one of the two will stop working (unless you
reload their bytecode files first, unsharing their collision chains).

Previous Next

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