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

[Pip Cet <pipcet@gmail.com>]

On Fri, Jul 5, 2019 at 1:59 AM Michael Heerdegen
<michael_heerdegen@web.de> wrote:
>
> Pip Cet <pipcet@gmail.com> writes:
>
> > As far as I can tell, this is a serious issue that will pop up
> > seemingly at random. We really should fix it.
>
> Yeah, it just happened again, when rebuilding a newer master version.
> And this time, cleaning and make bootstrap didn't fix it.  I still use
> the broken build FWIW as it's not as broken as the last time.

Is it still the same symptom, though?

> Anything I should do or try with it?

I'd like to verify it's indeed the bug I think it is. I think I could
figure that out if I had access to your Emacs binaries (emacs and
emacs.pdmp), but you can also debug things locally.

Can you do the following?

1. Run in gdb, with ASLR disabled
2. Set a breakpoint in print_vectorlike ("b print_vectorlike")
3. evaluate, in Emacs, (aref (aref (symbol-function
#'custom-handle-keyword) 2) 2)
4. wait for the breakpoint to be hit
5. in GDB, disable the breakpoint ("dis")
6. print and prettyprint the hash's next, hash, index, and
key_and_value vectors by typing, in gdb

p XHASH_TABLE(obj)->next
pp XHASH_TABLE(obj)->next
p XHASH_TABLE(obj)->hash
pp XHASH_TABLE(obj)->hash
p XHASH_TABLE(obj)->index
pp XHASH_TABLE(obj)->index
p XHASH_TABLE(obj)->key_and_value
pp XHASH_TABLE(obj)->key_and_value

(maybe you need to go up a stack frame or two so obj isn't optimized away).

7. Set a read/write breakpoint on the index table:

rwatch -l *(long *)&XHASH_TABLE(obj)->index
watch -l *(long *)XHASH_TABLE(obj)->index

8. Rerun emacs with gdb's "r" command, and find out where the
watchpoint is hit. In particular, if I'm right, it's accessed from two
different hash table objects.