From: Eli Zaretskii <eliz@gnu.org>
To: Romain Francoise <romain@orebokech.com>
Cc: 7952@debbugs.gnu.org
Subject: bug#7952: 24.0.50; crash in find_interval
Date: Sat, 19 Mar 2011 12:37:51 +0200 [thread overview]
Message-ID: <83r5a3qtts.fsf@gnu.org> (raw)
In-Reply-To: <87ei6417kl.fsf@silenus.orebokech.com>
> 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.
next prev parent reply other threads:[~2011-03-19 10:37 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.0.1296565545.10637.bug-gnu-emacs@gnu.org>
2011-03-09 12:25 ` bug#7952: 24.0.50; crash in find_interval Romain Francoise
2011-03-09 13:46 ` Eli Zaretskii
2011-03-09 15:16 ` Romain Francoise
2011-03-18 19:19 ` Romain Francoise
2011-03-18 19:37 ` Eli Zaretskii
2011-03-18 20:45 ` Romain Francoise
2011-03-19 10:37 ` Eli Zaretskii [this message]
2011-03-19 12:14 ` Andreas Schwab
2011-03-19 12:51 ` Eli Zaretskii
2011-03-19 13:18 ` Andreas Schwab
2011-03-19 13:56 ` Romain Francoise
2011-04-13 21:06 ` Chong Yidong
2011-04-14 4:36 ` Eli Zaretskii
2011-04-14 13:18 ` Romain Francoise
2011-04-26 8:39 ` Romain Francoise
2011-04-26 17:52 ` Eli Zaretskii
2011-04-29 18:17 ` Eli Zaretskii
2011-04-29 20:42 ` Romain Francoise
2011-04-30 8:58 ` Eli Zaretskii
2011-04-30 13:16 ` Stefan Monnier
2011-04-30 13:24 ` Eli Zaretskii
2011-05-02 14:51 ` Stefan Monnier
2011-05-08 5:18 ` Chong Yidong
2011-05-08 15:28 ` Eli Zaretskii
2011-05-08 20:27 ` Chong Yidong
2011-05-09 6:24 ` Eli Zaretskii
2011-05-09 14:06 ` Stefan Monnier
2011-05-09 14:46 ` Eli Zaretskii
2011-05-09 15:32 ` Stefan Monnier
2011-05-09 15:42 ` Eli Zaretskii
2011-05-09 17:09 ` Stefan Monnier
2011-05-09 19:46 ` Chong Yidong
2011-05-09 20:31 ` Eli Zaretskii
2011-02-01 12:41 Romain Francoise
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83r5a3qtts.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=7952@debbugs.gnu.org \
--cc=romain@orebokech.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).