bug#36447: 27.0.50; New "Unknown keyword" errors

[Pip Cet]

On Fri, Jul 5, 2019 at 8:25 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Fri, 5 Jul 2019 08:12:07 +0000
> > Cc: michael_heerdegen@web.de, npostavs@gmail.com, 36447@debbugs.gnu.org
> >
> > On Fri, Jul 5, 2019 at 7:50 AM Eli Zaretskii <eliz@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).