bug#7952: 24.0.50; crash in find_interval

[Eli Zaretskii <eliz@gnu.org>]

> From: Romain Francoise <romain@orebokech.com>
> Cc: 7952@debbugs.gnu.org
> Date: Fri, 18 Mar 2011 21:45:30 +0100
> 
> Also, this is not specific to my machine because I can
> reproduce it on fencepost. I generated a core file for you
> (~rfrancoise/emacs/core) if you want to have a closer look.

Now, that's one weird crash.  Observe:

  (gdb) bt 10
  #0  0x00007fd2af56dd57 in kill () from /lib/libc.so.6
  #1  0x000000000053bb1d in fatal_error_signal (sig=6) at emacs.c:342
  #2  <signal handler called>
  #3  0x00007fd2af56dd57 in kill () from /lib/libc.so.6
  #4  0x000000000053bb3c in abort () at emacs.c:371
  #5  0x0000000000648688 in find_interval (tree=0x0, position=255426) at intervals.c:635
  #6  0x000000000064af6f in set_point_both (charpos=255426, bytepos=255426) at intervals.c:2007
  #7  0x000000000048a9b2 in window_scroll_line_based (window=18497157, n=-49, whole=1, noerror=0) at window.c:5123
  #8  0x00000000004896cf in window_scroll (window=18497157, n=-1, whole=1, noerror=0) at window.c:4713
  #9  0x000000000048ad6d in scroll_command (n=12466818, direction=-1) at window.c:5246
  (More stack frames follow...)
  (gdb) frame 6
  #6  0x000000000064af6f in set_point_both (charpos=255426, bytepos=255426) at intervals.c:2007
  (gdb) l
  2007      to = find_interval (BUF_INTERVALS (current_buffer), charpos);
  2008      if (charpos == BEGV)
  2009        toprev = 0;
  2010      else if (to && to->position == charpos)
  2011        toprev = previous_interval (to);
  2012      else
  2013        toprev = to;
  2014
  2015      buffer_point = (PT == ZV ? ZV - 1 : PT);
  2016
  (gdb) p current_buffer->text->intervals
  $24 = (INTERVAL) 0x314b4c0
  (gdb) down
  #5  0x0000000000648688 in find_interval (tree=0x0, position=255426) at intervals.c:635
  (gdb) info address tree
  Symbol "tree" is a variable in $rax.
  (gdb)

current_buffer->text->intervals is the expansion of
"BUF_INTERVALS (current_buffer)" (btw, please use -g3 when you compile
an unoptimized version, because then the macro information is present
in the debug info in a form that GDB can use, rather than me having to
look up the macro in the sources and manually expand it).

So BUF_INTERVALS (current_buffer) is 0x314b4c0 in set_point_both, but
when find_interval is called with that value as the first argument,
the value winds up as zero inside find_interval!  The code in
find_interval leading to the abort is this:

  INTERVAL
  find_interval (register INTERVAL tree, register EMACS_INT position)
  {
    /* The distance from the left edge of the subtree at TREE
		      to POSITION.  */
    register EMACS_INT relative_position;

    if (NULL_INTERVAL_P (tree))
      return NULL_INTERVAL;

    relative_position = position;
    if (INTERVAL_HAS_OBJECT (tree))
      {
	Lisp_Object parent;
	GET_INTERVAL_OBJECT (parent, tree);
	if (BUFFERP (parent))
	  relative_position -= BUF_BEG (XBUFFER (parent));
      }

    if (relative_position > TOTAL_LENGTH (tree))
      abort ();			/* Paranoia */

There's nothing in this code that modifies `tree' in any way.  (I even
disassembled the code to make sure.)  So how come a non-NULL value
becomes NULL here?  Since this value is passed in a register by the
caller and kept in a register from the very beginning of the function,
not even some missing GCPRO somewhere could explain this.  What am I
missing?

Ideas are welcome.