[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#7952: 24.0.50; crash in find_interval
From: |
Eli Zaretskii |
Subject: |
bug#7952: 24.0.50; crash in find_interval |
Date: |
Sat, 19 Mar 2011 12:37:51 +0200 |
> 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.