[Top][All Lists]

[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: Fri, 29 Apr 2011 21:17:20 +0300

> Date: Tue, 26 Apr 2011 20:52:35 +0300
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden, address@hidden
> > From: Romain Francoise <address@hidden>
> > Cc: Chong Yidong <address@hidden>,  address@hidden
> > Date: Tue, 26 Apr 2011 10:39:10 +0200
> > 
> > Any chance some intervals expert could look at this bug?
> I'm no expert on this, but I will try this weekend, if no one beats me
> to it.

I found the reason.  It had nothing to do with intervals: in an Emacs
compiled with -DENABLE_CHECKING the crash happens earlier, inside
set_point_both, because the value of point passed to it is greater
than the buffer size.

The problem is that the new fontification in Grep buffers can modify
buffer text, e.g. when it finds an escape sequence emitted by Grep.
The other part of the puzzle is that vertical-motion, called from
window_scroll_line_based as part of handling M-v or C-v, enters
redisplay, which triggers JIT Lock fontification.  Here's the
Lisp-level backtrace from GDB; note the call to replace-match:

"replace-match" (0x82d760)
"progn" (0x82d940)
"eval" (0x82da14)
"font-lock-fontify-keywords-region" (0x82dc54)
"font-lock-default-fontify-region" (0x82de94)
"font-lock-fontify-region" (0x82e1f8)
"run-hook-with-args" (0x82e1f4)
"byte-code" (0x82e3a0)
"jit-lock-fontify-now" (0x82e774)
"jit-lock-function" (0x82eae4)
"scroll-down" (0x82f674)
"scroll-down-command" (0x82f8f4)
"call-interactively" (0x82fb84)

So the value of point saved by window_scroll_line_based becomes
invalid after vertical-motion returns, and the rest is history.

I fixed this on the trunk (revision 104055).  Emacs-23 branch has the
same problem, but I'd like to hear Stefan's and Chong's opinion
whether to install this change there as well (since Grep buffer
fontifications that trigger this problem were only introduced on the
trunk, and since the code in question survived without changes since
the 1990s).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]