bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Chong Yidong
Subject: bug#5365: 23.1.91; Wrong type argument: keymapp, ("DEAD" . 35215396)
Date: Wed, 13 Jan 2010 12:11:29 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux)

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

>> | #4  0x081324a5 in get_keymap (object=140861614, error=1, autoload=1) at 
>> keymap.c:307
>> | #5  0x08132d32 in keymap_parent (keymap=140861614, autoload=1) at 
>> keymap.c:321
>> | #6  0x08132dc9 in Fkeymap_parent (keymap=140861614) at keymap.c:341
>> ...
>> | Lisp Backtrace:
>> | "keymap-parent" (0xffa14acc)
>> | "x-setup-function-keys" (0xffa14c34)
>> | "x-create-frame-with-faces" (0xffa14db4)
>> | "make-frame" (0xffa14f34)
>> | "frame-initialize" (0xffa150b4)
>> | "command-line" (0xffa15234)
>> | "normal-top-level" (0xffa15330)
>> | (gdb)
>
> OK, so if we trust your backtrace (if you compiled with optimizations,
> there's a good chance that some parts of the backtrace aren't to be
> trusted, tho the Lisp part is less likely to be invented), the above
> implies that we're looking at the (keymap-parent local-function-key-map)
> call in x-win.el's x-setup-function-keys.

Sven, could you verify this?  In GDB, do

  f 5
  p keymap
  p current_kboard->Vlocal_function_key_map

The two values should be the same.

Even if that's the case, I'm not sure why Vlocal_function_key_map is
getting garbage-collected, tho.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]