GNU bug report logs - #7952
24.0.50; crash in find_interval

Previous Next

Package: emacs;

Reported by: Romain Francoise <romain <at> orebokech.com>

Date: Tue, 1 Feb 2011 12:34:02 UTC

Severity: normal

Found in version 24.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Romain Francoise <romain <at> orebokech.com>
Cc: cyd <at> stupidchicken.com, 7952 <at> debbugs.gnu.org
Subject: bug#7952: 24.0.50; crash in find_interval
Date: Sat, 30 Apr 2011 11:58:17 +0300
> From: Romain Francoise <romain <at> orebokech.com>
> Cc: cyd <at> stupidchicken.com,  7952 <at> debbugs.gnu.org
> Date: Fri, 29 Apr 2011 22:42:21 +0200
> 
> Not sure if it's related, but using grep results in lots of those in
> the Messages buffer:
> 
> | Error during redisplay: (args-out-of-range 26100 26140)
> | Error during redisplay: (args-out-of-range 55792 55803)
> | Error during redisplay: (args-out-of-range 89118 89155)
> | Error during redisplay: (args-out-of-range 107767 107804)
> | Error during redisplay: (args-out-of-range 119160 119176)
> | Error during redisplay: (args-out-of-range 152422 152434)

It's unrelated to the crash, but it's caused by the same reason:
jit-lock's function jit-lock-fontify-now also assumes that buffer
positions don't change as result of fontification.  The patch below,
which uses markers for those positions that can change, seems to fix
that.

Before I commit this, I'd appreciate a review by Stefan (and anyone
else who cares to comment), especially wrt to semi-kludgey updating of
jit-lock-context-unfontify-pos (I wasn't sure making it a marker would
be TRT).

=== modified file 'lisp/jit-lock.el'
--- lisp/jit-lock.el	2011-01-25 04:08:28 +0000
+++ lisp/jit-lock.el	2011-04-30 08:45:26 +0000
@@ -315,7 +315,8 @@ Defaults to the whole buffer.  END can b
   (with-buffer-prepared-for-jit-lock
    (save-excursion
      (unless start (setq start (point-min)))
-     (setq end (if end (min end (point-max)) (point-max)))
+     (setq end (copy-marker
+		(if end (min end (point-max)) (point-max))))
      ;; This did bind `font-lock-beginning-of-syntax-function' to
      ;; nil at some point, for an unknown reason.  Don't do this; it
      ;; can make highlighting slow due to expensive calls to
@@ -324,15 +325,16 @@ Defaults to the whole buffer.  END can b
      ;; from the end of a buffer to its start, can do repeated
      ;; `parse-partial-sexp' starting from `point-min', which can
      ;; take a long time in a large buffer.
-     (let ((orig-start start) next)
+     (let ((orig-start start)
+	   (next (make-marker)))
        (save-match-data
 	 ;; Fontify chunks beginning at START.  The end of a
 	 ;; chunk is either `end', or the start of a region
 	 ;; before `end' that has already been fontified.
 	 (while (and start (< start end))
 	   ;; Determine the end of this chunk.
-	   (setq next (or (text-property-any start end 'fontified t)
-			  end))
+	   (move-marker next (or (text-property-any start end 'fontified t)
+				 end))
 
 	   ;; Decide which range of text should be fontified.
 	   ;; The problem is that START and NEXT may be in the
@@ -340,7 +342,7 @@ Defaults to the whole buffer.  END can b
 	   ;; Until someone has a better idea, let's start
 	   ;; at the start of the line containing START and
 	   ;; stop at the start of the line following NEXT.
-	   (goto-char next)  (setq next (line-beginning-position 2))
+	   (goto-char next)  (move-marker next (line-beginning-position 2))
 	   (goto-char start) (setq start (line-beginning-position))
 
            ;; Make sure the contextual refontification doesn't re-refontify
@@ -353,7 +355,7 @@ Defaults to the whole buffer.  END can b
                       ;; it past the end of the multiline property and thus
                       ;; forget about this multiline region altogether.
                       (not (get-text-property start 'jit-lock-defer-multiline)))
-             (setq jit-lock-context-unfontify-pos next))
+             (setq jit-lock-context-unfontify-pos (marker-position next)))
 
 	   ;; Fontify the chunk, and mark it as fontified.
 	   ;; We mark it first, to make sure that we don't indefinitely
@@ -366,6 +368,13 @@ Defaults to the whole buffer.  END can b
 	     ;; before displaying the block again.
 	     (quit (put-text-property start next 'fontified nil)
 		   (funcall 'signal (car err) (cdr err))))
+	   ;; If NEXT moved as result of fontifying this chunk, update
+	   ;; jit-lock-context-unfontify-pos.
+	   (when (and jit-lock-context-unfontify-pos
+                      (>= jit-lock-context-unfontify-pos start)
+                      (> jit-lock-context-unfontify-pos next)
+                      (not (get-text-property start 'jit-lock-defer-multiline)))
+             (setq jit-lock-context-unfontify-pos (marker-position next)))
 
            ;; The redisplay engine has already rendered the buffer up-to
            ;; `orig-start' and won't notice if the above jit-lock-functions





This bug report was last modified 14 years and 17 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.