bug#5365: 23.1.91; Wrong type argument: keymapp, ("DEAD" . 35215396)

[Chong Yidong <cyd@stupidchicken.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Indeed, that looks risky.  Why don't we add this new kboard to the
>>> all_kboards list before calling Qvendor_specific_keysyms?
>> We'd still have to protect the terminal object.
>
> Why?  It's a normal Lisp object, so it should be protected by the usual
> GCPRO or stack marking, no?
> [ Oddly enough, mark_terminal doesn't traverse the terminal's kboard.  ]

But the terminal object is removed from the terminal list before the
call1 (this was before my latest patch):

 if (!EQ (XSYMBOL (Qvendor_specific_keysyms)->function, Qunbound))
   {
     char *vendor = ServerVendor (dpy);
     terminal_list = terminal->next_terminal;
     UNBLOCK_INPUT;
     terminal->kboard->Vsystem_key_alist
       = call1 (Qvendor_specific_keysyms,
                vendor ? build_string (vendor) : empty_unibyte_string);
     ...

This means that mark_terminal won't be able to reach the newly-allocated
terminal object, so its contents could get gc'ed.  I haven't checked
that there is anything in the terminal object that is actually in danger
of being gc'ed, but given some could hypothetically be added in the
future, it seems better to pre-emptively turn off gc during this
function call.