How to debug Error during redisplay

How to debug Error during redisplay

[Leo Liu]

I have just noticed this (using 24.2.92) in the *message* buffer which I
cannot reproduce in emacs 24.2. Any idea how to debug this problem?

Error during redisplay: (jit-lock-function 1) signaled (wrong-type-argument stringp nil)
Error during redisplay: (jit-lock-function 561) signaled (wrong-type-argument stringp nil)
Error during redisplay: (jit-lock-function 1) signaled (wrong-type-argument stringp nil) [2 times]

Leo

Re: How to debug Error during redisplay

[Eli Zaretskii]

> From: Leo Liu <sdl.web@gmail.com>
> Date: Fri, 11 Jan 2013 17:03:38 +0800
> 
> I have just noticed this (using 24.2.92) in the *message* buffer which I
> cannot reproduce in emacs 24.2. Any idea how to debug this problem?

Run Emacs under GDB, put a breakpoint in safe_eval_handler, and see
which code and in which buffer is responsible.

Re: How to debug Error during redisplay

[Leo Liu]

On 2013-01-11 18:25 +0800, Eli Zaretskii wrote:
> Run Emacs under GDB, put a breakpoint in safe_eval_handler, and see
> which code and in which buffer is responsible.

Thanks for the info; I have forgotten there is always GDB ;)

I don't know how to print current_buffer. I tried:

p current_buffer => $11 = (struct buffer *) 0x1015330a0
pr => 1079299112
xpr => Argument to arithmetic operation not a number or boolean.

But bt gives me this:

--------------------------------
Lisp Backtrace:
"redisplay_internal (C function)" (0x69d758)
"redisplay" (0x5fbf58a0)
"sit-for" (0x5fbf5f30)
"animate-string" (0x5fbf6480)
"if" (0x5fbf6990)
"let" (0x5fbf6cd0)
"progn" (0x5fbf6f30)
"if" (0x5fbf7190)
"slime-startup-message" (0x5fbf7428)
"funcall" (0x5fbf7420)
"slime-repl-update-banner" (0x5fbf7730)
"save-current-buffer" (0x5fbf7c50)
"slime-init-output-buffer" (0x5fbf7da0)
"slime-repl-connected-hook-function" (0x5fbf83c0)
"run-hooks" (0x5fbf83f0)
"let" (0x5fbf88f0)
"let" (0x5fbf8c30)
"ad-Orig-slime-set-connection-info" (0x5fbf8d80)
"with-no-warnings" (0x5fbf9320)
"setq" (0x5fbf9590)
"let" (0x5fbf98d0)
"slime-set-connection-info" (0x5fbf9b68)
"apply" (0x5fbf9c40)
0x5b1d840 Lisp type 6
"funcall" (0x5fbfa090)
"progn" (0x5fbfa4b0)
"if" (0x5fbfa710)
"let*" (0x5fbfaa30)
"progn" (0x5fbfac90)
"cond" (0x5fbfaf40)
"let*" (0x5fbfb260)
0x509f180 Lisp type 6
"apply" (0x5fbfb5b0)
0x5b1ce30 Lisp type 6
"slime-dispatch-event" (0x5fbfc0d0)
"slime-process-available-input" (0x5fbfc750)
"slime-net-filter" (0x5fbfcdc8)
--------------------------------

So this is triggered by animate-string which slime uses. Weirdly, the
same code doesn't have this error in 24.2.

Also if I set inhibit-eval-during-redisplay to t, the error is gone as
well.

Leo

Re: How to debug Error during redisplay

[Eli Zaretskii]

> From: Leo Liu <sdl.web@gmail.com>
> Date: Fri, 11 Jan 2013 19:02:29 +0800
> 
> On 2013-01-11 18:25 +0800, Eli Zaretskii wrote:
> > Run Emacs under GDB, put a breakpoint in safe_eval_handler, and see
> > which code and in which buffer is responsible.
> 
> Thanks for the info; I have forgotten there is always GDB ;)
> 
> I don't know how to print current_buffer.

 (gdb) pp current_buffer->name_

or

 (gdb) p current_buffer->name_
 (gdb) xstring

> So this is triggered by animate-string which slime uses. Weirdly, the
> same code doesn't have this error in 24.2.

Which code is that? can you show it?  Or does any use of
animate-string trigger these messages?

> Also if I set inhibit-eval-during-redisplay to t, the error is gone as
> well.

This should not surprise you, since that flag inhibits evaluation of
Lisp expressions during redisplay, including whatever expression that
causes the error.

Re: How to debug Error during redisplay

[Leo Liu]

On 2013-01-11 22:08 +0800, Eli Zaretskii wrote:
>  (gdb) pp current_buffer->name_
>
> or
>
>  (gdb) p current_buffer->name_
>  (gdb) xstring

Thanks. I figured it out too by reading DEBUG more carefully.

>> So this is triggered by animate-string which slime uses. Weirdly, the
>> same code doesn't have this error in 24.2.
>
> Which code is that? can you show it?  Or does any use of
> animate-string trigger these messages?

I mean the slime package, the same one running in 24.2 and 24.2.92. It
seems to me that in 24.2.92, the code is able to continue without
waiting for animate-string to finish. It feels more responsive.

>> Also if I set inhibit-eval-during-redisplay to t, the error is gone as
>> well.
>
> This should not surprise you, since that flag inhibits evaluation of
> Lisp expressions during redisplay, including whatever expression that
> causes the error.

Thanks.

Leo

Re: How to debug Error during redisplay

[Eli Zaretskii]

> From: Leo Liu <sdl.web@gmail.com>
> Date: Sat, 12 Jan 2013 13:25:10 +0800
> 
> >> So this is triggered by animate-string which slime uses. Weirdly, the
> >> same code doesn't have this error in 24.2.
> >
> > Which code is that? can you show it?  Or does any use of
> > animate-string trigger these messages?
> 
> I mean the slime package, the same one running in 24.2 and 24.2.92.

I downloaded the current snapshot of slime from
http://common-lisp.net/project/slime/.  Is this the package you are
talking about?  The only *.el file that calls animate-string there is
slime-banner.el:

  (defun slime-startup-message ()
    (when slime-header-line-p
      (setq header-line-format 
	    (format "%s  Port: %s  Pid: %s"
		    (slime-lisp-implementation-type)
		    (slime-connection-port (slime-connection))
		    (slime-pid))))
    (when (zerop (buffer-size))
      (let ((welcome (concat "; SLIME " (or (slime-changelog-date) 
					    "- ChangeLog file not found"))))
	(if slime-startup-animation
	    (animate-string welcome 0 0) 
	  (insert welcome)))))

Is this the code that produced the redisplay error messages?  If so, I
cannot reproduce this on my machine.  If this isn't the code in
question, then please show a minimal code snippet using animate-string
that does reproduce the problem.  (It isn't right to let me guess like
this, if you want the problem solved any time soon.)

> It seems to me that in 24.2.92, the code is able to continue without
> waiting for animate-string to finish. It feels more responsive.

I don't see how that could be true, but maybe I'm missing something.
In any case, is this a separate problem?

Re: How to debug Error during redisplay

[Leo Liu]

[-- Attachment #1: Type: text/plain, Size: 2505 bytes --]

On 2013-01-12 17:43 +0800, Eli Zaretskii wrote:
> I downloaded the current snapshot of slime from
> http://common-lisp.net/project/slime/.  Is this the package you are
> talking about?  The only *.el file that calls animate-string there is
> slime-banner.el:
>
>   (defun slime-startup-message ()
>     (when slime-header-line-p
>       (setq header-line-format 
> 	    (format "%s  Port: %s  Pid: %s"
> 		    (slime-lisp-implementation-type)
> 		    (slime-connection-port (slime-connection))
> 		    (slime-pid))))
>     (when (zerop (buffer-size))
>       (let ((welcome (concat "; SLIME " (or (slime-changelog-date) 
> 					    "- ChangeLog file not found"))))
> 	(if slime-startup-animation
> 	    (animate-string welcome 0 0) 
> 	  (insert welcome)))))
>
> Is this the code that produced the redisplay error messages?  If so, I
> cannot reproduce this on my machine.  If this isn't the code in
> question, then please show a minimal code snippet using animate-string
> that does reproduce the problem.  (It isn't right to let me guess like
> this, if you want the problem solved any time soon.)

Thanks for taking the trouble to investigate the issue further. I have
just spent an hour to come up with this reproduction recipe.

1. Install adaptive-wrap.el from ELPA
2. Install sbcl or clisp or any CL supported by slime
1. Emacs -q -l t.el (t.el assumes sbcl, which you may want to change)
2. M-x slime

My whole *Messages* buffer looks like this:

--------------------------------
For information about GNU Emacs and the GNU system, type C-h C-a.
`flet' is an obsolete macro (as of 24.3); use either `cl-flet' or `cl-letf'. [11 times]
Polling "/var/folders/mf/8_qnj_n146d0wxb32wdnb9jh0000gn/T/slime.13675" .. 1 (Abort with `M-x slime-abort-connection'.)
Polling "/var/folders/mf/8_qnj_n146d0wxb32wdnb9jh0000gn/T/slime.13675" .. 2 (Abort with `M-x slime-abort-connection'.)
Polling "/var/folders/mf/8_qnj_n146d0wxb32wdnb9jh0000gn/T/slime.13675" .. 3 (Abort with `M-x slime-abort-connection'.)
Polling "/var/folders/mf/8_qnj_n146d0wxb32wdnb9jh0000gn/T/slime.13675" .. 4 (Abort with `M-x slime-abort-connection'.)
Connecting to Swank on port 60501..
Error during redisplay: (jit-lock-function 1) signaled (wrong-type-argument stringp nil)
Error during redisplay: (jit-lock-function 520) signaled (wrong-type-argument stringp nil)
Error during redisplay: (jit-lock-function 1) signaled (wrong-type-argument stringp nil) [2 times]
Connected. Let the hacking commence!
--------------------------------


[-- Attachment #2: t.el --]
[-- Type: application/emacs-lisp, Size: 362 bytes --]

Re: How to debug Error during redisplay

[Leo Liu]

On 2013-01-12 19:56 +0800, Leo Liu wrote:
> 1. Install adaptive-wrap.el from ELPA
> 2. Install sbcl or clisp or any CL supported by slime
> 1. Emacs -q -l t.el (t.el assumes sbcl, which you may want to change)
> 2. M-x slime

A simpler recipe is:

1. M-x adaptive-wrap-prefix-mode
2. (animate-string "hello" 0)

So no need for slime or cl.

Leo

Re: How to debug Error during redisplay

[Eli Zaretskii]

> From: Leo Liu <sdl.web@gmail.com>
> Date: Sat, 12 Jan 2013 20:03:02 +0800
> 
> On 2013-01-12 19:56 +0800, Leo Liu wrote:
> > 1. Install adaptive-wrap.el from ELPA
> > 2. Install sbcl or clisp or any CL supported by slime
> > 1. Emacs -q -l t.el (t.el assumes sbcl, which you may want to change)
> > 2. M-x slime
> 
> A simpler recipe is:
> 
> 1. M-x adaptive-wrap-prefix-mode
> 2. (animate-string "hello" 0)
> 
> So no need for slime or cl.

Sorry, I cannot reproduce this here.  I did this:

 . M-x load-file RET elpa/packages/adaptive-wrap/adaptive-wrap.el RET

 . M-x adaptive-wrap-prefix-mode RET

 . M-: (animate-string "hello" 0) RET

And I don't see any error messages in *Messages*.

What am I doing wrong?

Re: How to debug Error during redisplay

[Leo Liu]

On 2013-01-12 21:49 +0800, Eli Zaretskii wrote:
>  . M-: (animate-string "hello" 0) RET
>
> And I don't see any error messages in *Messages*.

Your frame needs to be a wide as possible so that the inserted string by
animate-string is visible.

Leo

Re: How to debug Error during redisplay

[Eli Zaretskii]

> From:  Leo Liu <sdl.web@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 12 Jan 2013 21:58:20 +0800
> 
> On 2013-01-12 21:49 +0800, Eli Zaretskii wrote:
> >  . M-: (animate-string "hello" 0) RET
> >
> > And I don't see any error messages in *Messages*.
> 
> Your frame needs to be a wide as possible so that the inserted string by
> animate-string is visible.

Thanks, that was the missing link.  The backtrace is below, I hope
this will allow to fix adaptive-wrap.

For the record, here's how I got it caught red-handed:

 $ gdb ./emacs
 (gdb) break wrong_type_argument
 (gdb) r -Q

  Now do whatever it takes to reproduce the problem, and the
  breakpoint will break.

Evidently, the bug is here:

  (defun adaptive-wrap-fill-context-prefix (beg en)
    "Like `fill-context-prefix', but with length adjusted by `adaptive-wrap-extra-indent'."
    (let* ((fcp (fill-context-prefix beg en))
	   (fcp-len (string-width fcp))   <<<<<<<<<<<<<<<<<<<

It looks like this function doesn't expect that fill-context-prefix
could return nil.  But the ELisp manual says:

     Usually, this function returns the fill prefix, a string.  However,
     before doing this, the function makes a final check (not specially
     mentioned in the following) that a line starting with this prefix
     wouldn't look like the start of a paragraph.  Should this happen,
     the function signals the anomaly by returning `nil' instead.
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Here's the backtrace:

  Breakpoint 3, wrong_type_argument (predicate=56455034, value=56403994)
      at data.c:99
  99        xsignal2 (Qwrong_type_argument, predicate, value);
  (gdb) bt
  #0  wrong_type_argument (predicate=56455034, value=56403994) at data.c:99
  #1  0x01290bd4 in Fstring_width (str=56403994) at character.c:501
  #2  0x010131a1 in eval_sub (form=60154182) at eval.c:2037
  #3  0x0100fdfb in FletX (args=60186150) at eval.c:723
  #4  0x01012d17 in eval_sub (form=60154846) at eval.c:1985
  #5  0x0100f188 in Fprogn (args=60184958) at eval.c:359
  #6  0x01015c8c in funcall_lambda (fun=60184862, nargs=2, arg_vector=0x82a960)
      at eval.c:2897
  #7  0x010155d0 in apply_lambda (fun=60184862, args=60178750) at eval.c:2781
  #8  0x01013748 in eval_sub (form=60178758) at eval.c:2112
  #9  0x0101308e in eval_sub (form=60181702) at eval.c:2022
  #10 0x0100f188 in Fprogn (args=60178630) at eval.c:359
  #11 0x010103ce in Flet (args=60181710) at eval.c:818
  #12 0x01012d17 in eval_sub (form=60181886) at eval.c:1985
  #13 0x0100f188 in Fprogn (args=60178622) at eval.c:359
  #14 0x01010474 in Fwhile (args=60181902) at eval.c:840
  #15 0x01012d17 in eval_sub (form=60181950) at eval.c:1985
  #16 0x0100f188 in Fprogn (args=60178022) at eval.c:359
  #17 0x01015c8c in funcall_lambda (fun=60177702, nargs=2, arg_vector=0x82b23c)
      at eval.c:2897
  #18 0x0101536c in Ffuncall (nargs=3, args=0x82b238) at eval.c:2733
  #19 0x010140cd in funcall_nil (nargs=3, args=0x82b238) at eval.c:2218
  #20 0x01014536 in run_hook_with_args (nargs=3, args=0x82b238,
      funcall=0x10140b5 <funcall_nil>) at eval.c:2403
  #21 0x01014145 in Frun_hook_with_args (nargs=3, args=0x82b238) at eval.c:2264
  #22 0x01014bfd in Ffuncall (nargs=4, args=0x82b234) at eval.c:2653
  #23 0x0112765f in exec_byte_code (bytestr=20387929, vector=20946773,
      maxdepth=16, args_template=56403994, nargs=0, args=0x0) at bytecode.c:898
  #24 0x01126ad2 in Fbyte_code (bytestr=20387929, vector=20946773, maxdepth=16)
      at bytecode.c:473
  #25 0x01013283 in eval_sub (form=20946726) at eval.c:2043
  #26 0x01010caf in internal_lisp_condition_case (var=58254626,
      bodyform=20946726, handlers=20946798) at eval.c:1147
  #27 0x011280de in exec_byte_code (bytestr=20946369, vector=20946525,
      maxdepth=32, args_template=56403994, nargs=0, args=0x0) at bytecode.c:1094
  #28 0x01015dc0 in funcall_lambda (fun=20946349, nargs=2, arg_vector=0x82b818)
      at eval.c:2904
  #29 0x01015298 in Ffuncall (nargs=3, args=0x82b814) at eval.c:2721
  #30 0x0112765f in exec_byte_code (bytestr=20945985, vector=20946101,
      maxdepth=40, args_template=56403994, nargs=0, args=0x0) at bytecode.c:898
  #31 0x01015dc0 in funcall_lambda (fun=20945965, nargs=1, arg_vector=0x82bb64)
      at eval.c:2904
  #32 0x01015298 in Ffuncall (nargs=2, args=0x82bb60) at eval.c:2721
  #33 0x01011105 in internal_condition_case_n (bfun=0x1014852 <Ffuncall>,
      nargs=2, args=0x82bb60, handlers=56404018,
      hfun=0x1167501 <safe_eval_handler>) at eval.c:1317
  #34 0x0116761c in safe_call (nargs=2, func=60505498) at xdisp.c:2454
  #35 0x0116765c in safe_call1 (fn=60505498, arg=768) at xdisp.c:2470
  #36 0x0116ae0a in handle_fontified_prop (it=0x82c8b0) at xdisp.c:3690
  #37 0x01169e55 in handle_stop (it=0x82c8b0) at xdisp.c:3254
  #38 0x01179215 in next_element_from_buffer (it=0x82c8b0) at xdisp.c:7958
  #39 0x01174ca6 in get_next_display_element (it=0x82c8b0) at xdisp.c:6623
  #40 0x011a14e9 in display_line (it=0x82c8b0) at xdisp.c:19437
  #41 0x011962f9 in try_window (window=59219973, pos=..., flags=0)
      at xdisp.c:16301
  #42 0x01192f34 in redisplay_window (window=59219973, just_this_one_p=0)
      at xdisp.c:15632
  #43 0x0118c9e7 in redisplay_window_0 (window=59219973) at xdisp.c:13881
  #44 0x01010ec9 in internal_condition_case_1 (
      bfun=0x118c9b2 <redisplay_window_0>, arg=59219973, handlers=56388574,
      hfun=0x118c98e <redisplay_window_error>) at eval.c:1231
  #45 0x0118c97e in redisplay_windows (window=59219973) at xdisp.c:13861
  #46 0x0118af1d in redisplay_internal () at xdisp.c:13453
  #47 0x0118bf45 in redisplay_preserve_echo_area (from_where=2) at xdisp.c:13706
  #48 0x01080a7c in Fredisplay (force=56403994) at dispnew.c:5936
  #49 0x01014e91 in Ffuncall (nargs=1, args=0x82efa4) at eval.c:2672
  #50 0x0112765f in exec_byte_code (bytestr=20208233, vector=20208325,
      maxdepth=20, args_template=56403994, nargs=0, args=0x0) at bytecode.c:898
  #51 0x01015dc0 in funcall_lambda (fun=20208181, nargs=1, arg_vector=0x82f208)
      at eval.c:2904
  #52 0x01015298 in Ffuncall (nargs=2, args=0x82f204) at eval.c:2721
  #53 0x0112765f in exec_byte_code (bytestr=58311649, vector=56710557,
      maxdepth=28, args_template=56403994, nargs=0, args=0x0) at bytecode.c:898
  #54 0x01015dc0 in funcall_lambda (fun=56710669, nargs=2, arg_vector=0x82f3d0)
      at eval.c:2904
  #55 0x010155d0 in apply_lambda (fun=56710669, args=60243686) at eval.c:2781
  #56 0x010135a5 in eval_sub (form=60243694) at eval.c:2082
  #57 0x01012877 in Feval (form=60243694, lexical=56403994) at eval.c:1902
  #58 0x01014efc in Ffuncall (nargs=3, args=0x82f654) at eval.c:2675
  #59 0x0112765f in exec_byte_code (bytestr=20695897, vector=20695989,
      maxdepth=28, args_template=2052, nargs=2, args=0x82f8ac) at bytecode.c:898
  #60 0x0101597d in funcall_lambda (fun=20695869, nargs=2, arg_vector=0x82f8a4)
      at eval.c:2838
  #61 0x01015298 in Ffuncall (nargs=3, args=0x82f8a0) at eval.c:2721
  #62 0x01014089 in Fapply (nargs=2, args=0x82f940) at eval.c:2206
  #63 0x0101460d in apply1 (fn=58199234, arg=60243158) at eval.c:2440
  #64 0x0112489e in Fcall_interactively (function=58199234,
      record_flag=56403994, keys=56425333) at callint.c:377
  #65 0x01014f71 in Ffuncall (nargs=4, args=0x82fb80) at eval.c:2679
  #66 0x010146e2 in call3 (fn=56521306, arg1=58199234, arg2=56403994,
      arg3=56403994) at eval.c:2497
  #67 0x010aef10 in Fcommand_execute (cmd=58199234, record_flag=56403994,
      keys=56403994, special=56403994) at keyboard.c:10251
  #68 0x010954d5 in command_loop_1 () at keyboard.c:1588
  #69 0x01010db9 in internal_condition_case (bfun=0x109477b <command_loop_1>,
      handlers=56454362, hfun=0x1093fbb <cmd_error>) at eval.c:1193
  #70 0x01094407 in command_loop_2 (ignore=56403994) at keyboard.c:1175
  #71 0x010107c1 in internal_catch (tag=56444218,
      func=0x10943e4 <command_loop_2>, arg=56403994) at eval.c:964
  #72 0x010943bf in command_loop () at keyboard.c:1154
  #73 0x0109398c in recursive_edit_1 () at keyboard.c:787
  #74 0x01093cae in Frecursive_edit () at keyboard.c:851
  #75 0x01002872 in main (argc=2, argv=0xa427c8) at emacs.c:1573

  Lisp Backtrace:
  "string-width" (0x82a670)
  "let*" (0x82a890)
  "adaptive-wrap-fill-context-prefix" (0x82a960)
  "put-text-property" (0x82ac00)
  "let" (0x82ae00)
  "while" (0x82afa0)
  "adaptive-wrap-prefix-function" (0x82b23c)
  "run-hook-with-args" (0x82b238)
  "byte-code" (0x82b410)
  "jit-lock-fontify-now" (0x82b818)
  "jit-lock-function" (0x82bb64)
  "redisplay_internal (C function)" (0x166c7f0)
  "redisplay" (0x82efa8)
  "sit-for" (0x82f208)
  "animate-string" (0x82f3d0)
  "eval" (0x82f658)
  "eval-expression" (0x82f8a4)
  "call-interactively" (0x82fb84)
  (gdb)

Re: How to debug Error during redisplay

[Stephen Berman]

On Sat, 12 Jan 2013 16:31:58 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From:  Leo Liu <sdl.web@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Sat, 12 Jan 2013 21:58:20 +0800
>> 
>> On 2013-01-12 21:49 +0800, Eli Zaretskii wrote:
>> >  . M-: (animate-string "hello" 0) RET
>> >
>> > And I don't see any error messages in *Messages*.
>> 
>> Your frame needs to be a wide as possible so that the inserted string by
>> animate-string is visible.
>
> Thanks, that was the missing link.  The backtrace is below, I hope
> this will allow to fix adaptive-wrap.
>
> For the record, here's how I got it caught red-handed:
>
>  $ gdb ./emacs
>  (gdb) break wrong_type_argument
>  (gdb) r -Q
>
>   Now do whatever it takes to reproduce the problem, and the
>   breakpoint will break.
>
> Evidently, the bug is here:
>
>   (defun adaptive-wrap-fill-context-prefix (beg en)
>     "Like `fill-context-prefix', but with length adjusted by `adaptive-wrap-extra-indent'."
>     (let* ((fcp (fill-context-prefix beg en))
> 	   (fcp-len (string-width fcp))   <<<<<<<<<<<<<<<<<<<
>
> It looks like this function doesn't expect that fill-context-prefix
> could return nil.  But the ELisp manual says:
>
>      Usually, this function returns the fill prefix, a string.  However,
>      before doing this, the function makes a final check (not specially
>      mentioned in the following) that a line starting with this prefix
>      wouldn't look like the start of a paragraph.  Should this happen,
>      the function signals the anomaly by returning `nil' instead.
>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The simplest fix seems to be for the fill prefix to default to "", as in
the patch below, which prevents the redisplay error, though I cannot
tell whether the resulting failure to "signal the anomaly" could have
undesirable consequences.

Steve Berman

*** /tmp/ediff4143yqw	2013-01-12 18:02:35.482163188 +0100
--- /tmp/ediff4143_02	2013-01-12 18:02:35.525164198 +0100
***************
*** 1,6 ****
  (defun adaptive-wrap-fill-context-prefix (beg en)
!   "Like `fill-context-prefix', but with length adjusted by `adaptive-wrap-extra-indent'."
!   (let* ((fcp (fill-context-prefix beg en))
           (fcp-len (string-width fcp))
           (fill-char (if (< 0 fcp-len)
                          (string-to-char (substring fcp -1))
--- 1,8 ----
  (defun adaptive-wrap-fill-context-prefix (beg en)
!   "Compute a fill prefix from the text between BEG and EN.
! Like `fill-context-prefix', but with length adjusted by
! `adaptive-wrap-extra-indent'."
!   (let* ((fcp (or (fill-context-prefix beg en) ""))
           (fcp-len (string-width fcp))
           (fill-char (if (< 0 fcp-len)
                          (string-to-char (substring fcp -1))

Re: How to debug Error during redisplay

[Eli Zaretskii]

> From: Leo Liu <sdl.web@gmail.com>
> Date: Sat, 12 Jan 2013 19:56:59 +0800
> 
> 1. Install adaptive-wrap.el from ELPA
> 2. Install sbcl or clisp or any CL supported by slime
> 1. Emacs -q -l t.el (t.el assumes sbcl, which you may want to change)
> 2. M-x slime

Thanks, so it sounds like the culprit might be adaptive-wrap, and not
slime or animate-string.

However, I hope there's a simpler way to debug this.  Please run Emacs
under GDB, put a breakpoint in Fstringp, where it is about to return
Qnil:

  DEFUN ("stringp", Fstringp, Sstringp, 1, 1, 0,
	 doc: /* Return t if OBJECT is a string.  */)
    (Lisp_Object object)
  {
    if (STRINGP (object))
      return Qt;
    return Qnil; <<<<<<<<<<<<<<<<<<<<<<<<
  }

and then run your recipe to reproduce the problem.  (I hope this
breakpoint won't break too many times in unrelated cases; if it does,
we can figure out a way to make the breakpoint smarter.)  When the
breakpoint breaks, the backtrace should tell us which Lisp code caused
it.  Please show both the C and Lisp parts of the backtrace.

Thanks.

Re: How to debug Error during redisplay

[Stefan Monnier]

> I have just noticed this (using 24.2.92) in the *message* buffer which I
> cannot reproduce in emacs 24.2. Any idea how to debug this problem?

> Error during redisplay: (jit-lock-function 1) signaled (wrong-type-argument stringp nil)
> Error during redisplay: (jit-lock-function 561) signaled (wrong-type-argument stringp nil)
> Error during redisplay: (jit-lock-function 1) signaled (wrong-type-argument stringp nil) [2 times]

You can try (setq font-lock-support-mode nil) then turn font-lock-mode off
and then back on, so as to make it not use jit-lock.  If you're lucky,
the same problem will occur, but this time it'll be in a context where
debug-on-error works.


        Stefan

Re: How to debug Error during redisplay

[Leo Liu]

On 2013-01-11 22:56 +0800, Stefan Monnier wrote:
> You can try (setq font-lock-support-mode nil) then turn font-lock-mode off
> and then back on, so as to make it not use jit-lock.  If you're lucky,
> the same problem will occur, but this time it'll be in a context where
> debug-on-error works.

But I couldn't get it to work. I did:

1. M-: (setq font-lock-support-mode nil)
2. M-x font-lock-mode
3. M-x font-lock-mode

Regards,
Leo

Re: How to debug Error during redisplay

[Stefan Monnier]

>> You can try (setq font-lock-support-mode nil) then turn font-lock-mode off
>> and then back on, so as to make it not use jit-lock.  If you're lucky,
>> the same problem will occur, but this time it'll be in a context where
>> debug-on-error works.
> But I couldn't get it to work. I did:
> 1. M-: (setq font-lock-support-mode nil)
> 2. M-x font-lock-mode
> 3. M-x font-lock-mode

Indeed, adaptive-wrap uses jit-lock directly and not font-lock, so the
above doesn't help.
We should really improve jit-lock.el to provide a "debugging mode" where
it somehow runs the code at some other time than during redisplay, so it
can be debugged better.


        Stefan

Re: How to debug Error during redisplay

[Leo Liu]

On 2013-01-12 21:08 +0800, Stefan Monnier wrote:
> We should really improve jit-lock.el to provide a "debugging mode" where
> it somehow runs the code at some other time than during redisplay, so it
> can be debugged better.

Is it possible to teach it to be verbose in this case?

In time of this, I find myself hoping the message can tell me which
function other than jit-lock-function has caused the error.

Leo

Re: How to debug Error during redisplay

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 12 Jan 2013 08:08:53 -0500
> Cc: emacs-devel@gnu.org
> 
> We should really improve jit-lock.el to provide a "debugging mode" where
> it somehow runs the code at some other time than during redisplay, so it
> can be debugged better.

Or provide a debugging mode in safe_eval, so that it would, e.g., save
a backtrace in some variable, instead of showing just the innermost
expression that threw an error.

Re: How to debug Error during redisplay

[Leo Liu]

On 2013-01-12 21:52 +0800, Eli Zaretskii wrote:
> Or provide a debugging mode in safe_eval, so that it would, e.g., save
> a backtrace in some variable, instead of showing just the innermost
> expression that threw an error.

+1

Leo

Re: How to debug Error during redisplay

[Stefan Monnier]

> Or provide a debugging mode in safe_eval, so that it would, e.g., save
> a backtrace in some variable, instead of showing just the innermost
> expression that threw an error.

That would help as well, yes (and the two are not mutually exclusive).


        Stefan