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

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

[Richard M. Stallman]

    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 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.

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

[Joe Wells]

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

"Richard M. Stallman" <rms@gnu.org> 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

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

[Andreas Schwab]

Joe Wells <jbw@macs.hw.ac.uk> writes:

> 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.

Probably the easiest way to find the bug is to set a watchpoint on Qnil.
That value should not ever change during runtime of Emacs (temacs
initializes it once in init_obarray).  Another place to watch is the hash
entry of the symbol nil in Vobarray.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Eli Zaretskii]

> From: Joe Wells <jbw@macs.hw.ac.uk>
> Date: Fri, 24 Feb 2006 00:26:15 +0000
> Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org
> 
> 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

Does the GDB command "info symbol 0x08554f28" display something
useful?  Also try "print/a 0x08554f28".

I agree with Andreas that putting a watchpoint on Qnil's address and
on its obarray entry (and on any other places thru which Qnil can be
modified) is the best strategy, given the data you've gather so far.