emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Emacs-bug-tracker] bug#7952: closed (24.0.50; crash in find_interval)


From: GNU bug Tracking System
Subject: [Emacs-bug-tracker] bug#7952: closed (24.0.50; crash in find_interval)
Date: Fri, 29 Apr 2011 18:18:02 +0000

Your message dated Fri, 29 Apr 2011 21:17:20 +0300
with message-id <address@hidden>
and subject line Re: bug#7952: 24.0.50; crash in find_interval
has caused the GNU bug report #7952,
regarding 24.0.50; crash in find_interval
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
7952: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7952
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 24.0.50; crash in find_interval Date: Tue, 01 Feb 2011 13:41:08 +0100
Emacs from Git as of revision 4817a832f49, which corresponds to the
bzr trunk as of revision 103065, crashes in find_interval() when I
move around grep buffers:

| Core was generated by `./src/emacs -nw'.
| Program terminated with signal 6, Aborted.
| #0  0x00007fc45c00c447 in kill () at ../sysdeps/unix/syscall-template.S:82
| 82      ../sysdeps/unix/syscall-template.S: No such file or directory.
|         in ../sysdeps/unix/syscall-template.S
| (gdb) bt
| #0  0x00007fc45c00c447 in kill () at ../sysdeps/unix/syscall-template.S:82
| #1  0x000000000055b203 in fatal_error_signal (sig=6) at emacs.c:343
| #2  <signal handler called>
| #3  0x00007fc45c00c447 in kill () at ../sysdeps/unix/syscall-template.S:82
| #4  0x000000000055b222 in abort () at emacs.c:372
| #5  0x0000000000669960 in find_interval (tree=0x0, position=1559343)
|     at intervals.c:635
| #6  0x000000000066c116 in set_point_both (charpos=1559343, bytepos=1559964)
|     at intervals.c:2008
| #7  0x000000000048da2d in window_scroll_line_based (window=43271749, n=-49,
|     whole=1, noerror=0) at window.c:5125
| #8  0x000000000048c726 in window_scroll (window=43271749, n=-1, whole=1,
|     noerror=0) at window.c:4715
| #9  0x000000000048dde8 in scroll_command (n=12601730, direction=-1)
|     at window.c:5248
| #10 0x000000000048deb6 in Fscroll_down (arg=12601730) at window.c:5282
| #11 0x00000000005ffb32 in Ffuncall (nargs=2, args=0x7fff5c4c84b0)
|     at eval.c:2842
| #12 0x000000000064bac7 in Fbyte_code (bytestr=10424209, vector=10424245,
|     maxdepth=12) at bytecode.c:676
| #13 0x0000000000600430 in funcall_lambda (fun=10424149, nargs=1,
|     arg_vector=0x7fff5c4c8958) at eval.c:3028
| #14 0x00000000005ffd3f in Ffuncall (nargs=2, args=0x7fff5c4c8950)
|     at eval.c:2891
| #15 0x00000000005fa4ad in Fcall_interactively (function=12963906,
|     record_flag=12601730, keys=12649141) at callint.c:842
| #16 0x00000000005ffb88 in Ffuncall (nargs=4, args=0x7fff5c4c8cd0)
|     at eval.c:2849
| #17 0x00000000005ff539 in call3 (fn=12788898, arg1=12963906, arg2=12601730,
|     arg3=12601730) at eval.c:2674
| #18 0x000000000057250c in Fcommand_execute (cmd=12963906,
|     record_flag=12601730, keys=12601730, special=12601730) at keyboard.c:10180
| #19 0x000000000055ff27 in command_loop_1 () at keyboard.c:1528
| #20 0x00000000005fccad in internal_condition_case (
|     bfun=0x55f711 <command_loop_1>, handlers=12653922,
|     hfun=0x55f019 <cmd_error>) at eval.c:1408
| #21 0x000000000055f412 in command_loop_2 (ignore=12601730) at keyboard.c:1129
| #22 0x00000000005fc64a in internal_catch (tag=12649938,
|     func=0x55f3ec <command_loop_2>, arg=12601730) at eval.c:1152
| #23 0x000000000055f3c5 in command_loop () at keyboard.c:1108
| #24 0x000000000055eb50 in recursive_edit_1 () at keyboard.c:731
| #25 0x000000000055ed03 in Frecursive_edit () at keyboard.c:793
| #26 0x000000000055d04d in main (argc=2, argv=0x7fff5c4c96d8) at emacs.c:1682
| (gdb)

Steps to reproduce:
1) Start ./src/emacs -nw in the top-level of the source tree
2) Do M-x grep-find RET emacs RET
3) Do C-x 0 to maximize the window with *grep* buffer
4) Move around with C-v/M-v until it crashes

This may be related bug #7920, but I'm not sure.



--- End Message ---
--- Begin Message --- Subject: Re: 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).


--- End Message ---

reply via email to

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