Re: nil became bound to (#<save_value ptr=0x085526f0 int=0> 96536 96288)

[Joe Wells]

[ I am CC-ing this message to address@hidden only so that
  readers of that list can see that the discussion has moved to
  address@hidden, where Richard seems to prefer having it.
  Please remove address@hidden from any further
  followups. ]

"Richard M. Stallman" <address@hidden> writes:

>     Somehow in an invocation of Emacs, the symbol nil became bound to a
>     value that prints as this:
>
>       (#<save_value ptr=0x085526f0 int=0> 96536 96288)
>
> Yowch!
>
> There are not many places in Emacs that make a save-value.
> Perhaps you can reconstruct the C-level value that was saved
> by looking at that data, and then perhaps you can figure out
> where the save-value was actually made.

It happened again!  This is the second time it has ever happened to
me.

This time the value of nil printed like this:

  (#<save_value ptr=0x08554f28 int=0>)

I think this tends to cast doubt on Eli's idea that it might be a
faulty memory chip, as that would not tend to cause such a similar
problem without causing lots of other problems.

I attached gdb to the crippled-but-not-dead-yet process.
Cross-checking with the source code, I wasn't able to figure out how
to make any sense of the data at 0x08554f28.  I somehow doubt this
will help, but in case this is somehow easy here is what gdb reported
as the contents of the 8 words (32 bytes) starting at that location:

(gdb) x/8xw 0x08554f28
0x8554f28:      0x084bf340      0x085544c0      0x00000004      0x00000003
0x8554f38:      0x0000000b      0x00000000      0x085544e8      0x00a00000

"uname -a" says:

  Linux colinux 2.6.8.1-co-0.6.2-pre1 #1 Sat Sep 11 03:10:51 WEST 2004 i686 
Intel(R) Pentium(R) M processor 1100MHz GNU/Linux

Although the data at the far end of the pointer didn't seem helpful, I
was intrigued by the fact that the value of nil was a _list_ whose car
was built by make_save_value.  These values do not (in theory) escape
into user Lisp land, so it might be relevant to look at all the places
that build cons cells containing save-values.  There are only three
such places: map_keymap (keymap.c), xmenu_show (xmenu.c),
x_check_errors (xterm.c).  xmenu_show always builds a cons with two
save-values, one in the car and the other in the cdr; this seems to
rule it out because in this error the cdr is either nil or a list of
two numbers.  x_check_errors builds a cons with the car a save-value
and the cdr the value of x_error_message_string, which should be a
string or nil; again this seems ruled out.  map_keymap conses two
save-values onto an arbitrary user-supplied Lisp value, so potentially
the inner cons it builds could be the value that is being assigned to
nil.  However, looking at the code, it looks like the only possible
place that the outer cons could be deconstructed is in
map_keymap_char_table_item, and it immediately deconstructs the inner
cons as well, so that seems to rule this out.

So I'm wondering instead if something is smashing what specpdl_ptr
points to.  The code in unbind_to will happily assign the value of
specpdl_ptr->old_value to specpdl_ptr->symbol if specpdl_ptr->func is
0.  There are lots of places that put save-values in
specpdl_ptr->old_value at the same time as they put Qnil in
specpdl_ptr->symbol.  However, none of them puts in
specpdl_ptr->old_value a _cons_ whose _car_ is a save-value and whose
_cdr_ can either be nil or a list of two integers.  The conses built
by map_keymap don't appear to come anywhere near
record_unwind_protect, and hence I don't see how they could get into
one of the structures pointed to by specpdl_ptr.

A mystery.

For what it is worth, the source for the exact version of Emacs I am
using can be found at this location:

  
http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/distfiles/emacs-22.0.50-20050225.tar.gz

> It is possible that this is a bug already fixed, as someone else
> pointed out; but it's also possible that this bug is just rare.
> So I think a little more investigation would be worth doing
> if you want to.

-- 
Joe