From: Chong Yidong <cyd@stupidchicken.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Sven Joachim <svenjoac@gmx.de>, 5365@debbugs.gnu.org
Subject: bug#5365: 23.1.91; Wrong type argument: keymapp, ("DEAD" . 35215396)
Date: Fri, 15 Jan 2010 11:27:05 -0500 [thread overview]
Message-ID: <873a27z63q.fsf@stupidchicken.com> (raw)
In-Reply-To: <jwvaawhtjc9.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Wed, 13 Jan 2010 23:21:00 -0500")
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.
next prev parent reply other threads:[~2010-01-15 16:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-12 14:58 bug#5365: 23.1.91; Wrong type argument: keymapp, ("DEAD" . 35215396) Sven Joachim
2010-01-13 10:03 ` Sven Joachim
2010-01-13 15:17 ` Stefan Monnier
2010-01-13 17:11 ` Chong Yidong
2010-01-13 17:27 ` Chong Yidong
2010-01-13 18:57 ` Stefan Monnier
2010-01-13 20:53 ` Chong Yidong
2010-01-14 4:21 ` Stefan Monnier
2010-01-15 16:27 ` Chong Yidong [this message]
2010-01-15 17:52 ` Stefan Monnier
2010-01-13 19:13 ` Sven Joachim
2010-01-13 18:46 ` Sven Joachim
-- strict thread matches above, loose matches on Subject: below --
2010-01-12 19:08 Chong Yidong
2010-01-12 19:39 ` Sven Joachim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=873a27z63q.fsf@stupidchicken.com \
--to=cyd@stupidchicken.com \
--cc=5365@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=svenjoac@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.