bug#28850: 26.0.90; Error running timer 'jit-lock-stealth-fontify': (error "Invalid search bound (wrong side of point)")

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

Sorry it's taken me a little time to answer you.  I was rather busy with
another bug.

On Wed, May 01, 2019 at 21:49:07 +0300, Eli Zaretskii wrote:
> > Date: Tue, 30 Apr 2019 18:26:26 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: acm@muc.de, 28850@debbugs.gnu.org
> > 
> > FWIW, I think I see something similar in Emacs 26.2, I will try to
> > catch it one of these days.

> Done.  The error messages are slightly different: wrong-type-argument
> number-or-marker-p nil.

> It was very hard to debug, but eventually I succeeded to catch a
> backtrace:

>   Thread 1 hit Breakpoint 5, wrong_type_argument (predicate=XIL(0x9f90),
>       value=XIL(0)) at data.c:146
>   146     {
>   #0  wrong_type_argument (predicate=XIL(0x9f90), value=XIL(0)) at data.c:146
>   #1  0x01127519 in CHECK_TYPE (x=XIL(0), predicate=<optimized out>, ok=0)
>       at lisp.h:625

[ .... ]


>   Lisp Backtrace:
>   "1+" (0x88acd0)
>   "goto-char" (0x88adb8)
>   "save-excursion" (0x88aee8)
>   "cond" (0x88aff8)
>   "setq" (0x88b138)
>   "let" (0x88b2b8)
>   "if" (0x88b3d8)
>   "catch" (0x88b548)
>   "while" (0x88b668)
>   "if" (0x88b788)
>   "save-restriction" (0x88b8b8)
>   "let" (0x88baf8)
>   "c-beginning-of-statement-1" (0x88bbf0)
>   "setq" (0x88be48)
>   "eq" (0x88bf38)
>   "not" (0x88c028)
>   "and" (0x88c138)
>   "while" (0x88c258)
>   "let" (0x88c3d8)
>   "let*" (0x88c528)
>   "catch" (0x88c698)
>   "c-beginning-of-decl-1" (0x88c810)
>   0xadfab48 PVEC_COMPILED
>   "font-lock-fontify-keywords-region" (0x88d0c0)
>   "font-lock-default-fontify-region" (0x88d410)
>   "c-font-lock-fontify-region" (0x88d740)
>   "font-lock-fontify-region" (0x88d9e8)
>   0x18b47060 PVEC_COMPILED
>   "run-hook-wrapped" (0x88de00)
>   "jit-lock--run-functions" (0x88e150)
>   "jit-lock-fontify-now" (0x88e5b0)
>   "jit-lock-stealth-fontify" (0x88ea60)
>   "apply" (0x88ea58)
>   "timer-event-handler" (0x88eda8)

> This comes from the following code fragment:

>   (defun c-beginning-of-statement-1 (&optional lim ignore-labels
> 					       noerror comma-delim)
>   [...]
> 			   ;; Just gone back over some paren block?
> 			   ((looking-at "\\s(")
> 			    (save-excursion
> 			      (goto-char (1+ (c-down-list-backward
> 					      before-sws-pos)))
> 			      (c-crosses-statement-barrier-p
> 			       (point) maybe-after-boundary-pos)))

> c-down-list-backward is documented to be able to return nil, so
> passing the result to 1+ is unsafe.

The movement function which brought point to that "\\s(" was
c-backward-sexp, i.e. (goto-char (scan-sexps (point) -1)), so the nil
that you got from c-down-list-backward "can't possibly happen".  :-(

> I cannot claim a good understanding of the code, ....

Long ago, that function, before it was rewritten by Martin Stjernholm,
carried the comment "if you think you understand this function you are
probably mistaken." ;-).

> .... but the following ad-hoc patch fixes the problem for me:

> --- lisp/progmodes/cc-engine.el~0	2019-01-07 16:26:06.000000000 +0200
> +++ lisp/progmodes/cc-engine.el	2019-05-01 14:43:35.823456200 +0300
> @@ -1130,10 +1130,12 @@
>  			 ;; Just gone back over some paren block?
>  			 ((looking-at "\\s(")
>  			  (save-excursion
> -			    (goto-char (1+ (c-down-list-backward
> -					    before-sws-pos)))
> -			    (c-crosses-statement-barrier-p
> -			     (point) maybe-after-boundary-pos)))
> +			    (let ((pos1 (c-down-list-backward
> +					 before-sws-pos)))
> +			      (when (number-or-marker-p pos1)
> +				(goto-char (1+ pos1))
> +				(c-crosses-statement-barrier-p
> +				 (point) maybe-after-boundary-pos)))))
>  			 ;; Just gone back over an ordinary symbol of some sort?
>  			 (t (c-crosses-statement-barrier-p
>  			     (point) maybe-after-boundary-pos))))

However, that nil clearly did happen, so I'll be spending some time
working out how it could have happened, and amending
c-beginning-of-statement-1 accordingly, whether with your ad-hoc patch
or otherwise.

Thanks for taking so much time and trouble to get that stack trace.

-- 
Alan Mackenzie (Nuremberg, Germany).