* How to debug Error during redisplay @ 2013-01-11 9:03 Leo Liu 2013-01-11 10:25 ` Eli Zaretskii 2013-01-11 14:56 ` Stefan Monnier 0 siblings, 2 replies; 20+ messages in thread From: Leo Liu @ 2013-01-11 9:03 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to debug Error during redisplay 2013-01-11 9:03 How to debug Error during redisplay Leo Liu @ 2013-01-11 10:25 ` Eli Zaretskii 2013-01-11 11:02 ` Leo Liu 2013-01-11 14:56 ` Stefan Monnier 1 sibling, 1 reply; 20+ messages in thread From: Eli Zaretskii @ 2013-01-11 10:25 UTC (permalink / raw) To: Leo Liu; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to debug Error during redisplay 2013-01-11 10:25 ` Eli Zaretskii @ 2013-01-11 11:02 ` Leo Liu 2013-01-11 14:08 ` Eli Zaretskii 0 siblings, 1 reply; 20+ messages in thread From: Leo Liu @ 2013-01-11 11:02 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to debug Error during redisplay 2013-01-11 11:02 ` Leo Liu @ 2013-01-11 14:08 ` Eli Zaretskii 2013-01-12 5:25 ` Leo Liu 0 siblings, 1 reply; 20+ messages in thread From: Eli Zaretskii @ 2013-01-11 14:08 UTC (permalink / raw) To: Leo Liu; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to debug Error during redisplay 2013-01-11 14:08 ` Eli Zaretskii @ 2013-01-12 5:25 ` Leo Liu 2013-01-12 9:43 ` Eli Zaretskii 0 siblings, 1 reply; 20+ messages in thread From: Leo Liu @ 2013-01-12 5:25 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to debug Error during redisplay 2013-01-12 5:25 ` Leo Liu @ 2013-01-12 9:43 ` Eli Zaretskii 2013-01-12 11:56 ` Leo Liu 0 siblings, 1 reply; 20+ messages in thread From: Eli Zaretskii @ 2013-01-12 9:43 UTC (permalink / raw) To: Leo Liu; +Cc: emacs-devel > 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? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to debug Error during redisplay 2013-01-12 9:43 ` Eli Zaretskii @ 2013-01-12 11:56 ` Leo Liu 2013-01-12 12:03 ` Leo Liu 2013-01-12 12:30 ` Eli Zaretskii 0 siblings, 2 replies; 20+ messages in thread From: Leo Liu @ 2013-01-12 11:56 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to debug Error during redisplay 2013-01-12 11:56 ` Leo Liu @ 2013-01-12 12:03 ` Leo Liu 2013-01-12 13:49 ` Eli Zaretskii 2013-01-12 12:30 ` Eli Zaretskii 1 sibling, 1 reply; 20+ messages in thread From: Leo Liu @ 2013-01-12 12:03 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to debug Error during redisplay 2013-01-12 12:03 ` Leo Liu @ 2013-01-12 13:49 ` Eli Zaretskii 2013-01-12 13:58 ` Leo Liu 0 siblings, 1 reply; 20+ messages in thread From: Eli Zaretskii @ 2013-01-12 13:49 UTC (permalink / raw) To: Leo Liu; +Cc: emacs-devel > 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? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to debug Error during redisplay 2013-01-12 13:49 ` Eli Zaretskii @ 2013-01-12 13:58 ` Leo Liu 2013-01-12 14:31 ` Eli Zaretskii 0 siblings, 1 reply; 20+ messages in thread From: Leo Liu @ 2013-01-12 13:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to debug Error during redisplay 2013-01-12 13:58 ` Leo Liu @ 2013-01-12 14:31 ` Eli Zaretskii 2013-01-12 17:17 ` Stephen Berman 0 siblings, 1 reply; 20+ messages in thread From: Eli Zaretskii @ 2013-01-12 14:31 UTC (permalink / raw) To: Leo Liu; +Cc: emacs-devel > 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) ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to debug Error during redisplay 2013-01-12 14:31 ` Eli Zaretskii @ 2013-01-12 17:17 ` Stephen Berman 0 siblings, 0 replies; 20+ messages in thread From: Stephen Berman @ 2013-01-12 17:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Leo Liu, emacs-devel 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)) ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to debug Error during redisplay 2013-01-12 11:56 ` Leo Liu 2013-01-12 12:03 ` Leo Liu @ 2013-01-12 12:30 ` Eli Zaretskii 1 sibling, 0 replies; 20+ messages in thread From: Eli Zaretskii @ 2013-01-12 12:30 UTC (permalink / raw) To: Leo Liu; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to debug Error during redisplay 2013-01-11 9:03 How to debug Error during redisplay Leo Liu 2013-01-11 10:25 ` Eli Zaretskii @ 2013-01-11 14:56 ` Stefan Monnier 2013-01-12 5:26 ` Leo Liu 1 sibling, 1 reply; 20+ messages in thread From: Stefan Monnier @ 2013-01-11 14:56 UTC (permalink / raw) To: Leo Liu; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to debug Error during redisplay 2013-01-11 14:56 ` Stefan Monnier @ 2013-01-12 5:26 ` Leo Liu 2013-01-12 13:08 ` Stefan Monnier 0 siblings, 1 reply; 20+ messages in thread From: Leo Liu @ 2013-01-12 5:26 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to debug Error during redisplay 2013-01-12 5:26 ` Leo Liu @ 2013-01-12 13:08 ` Stefan Monnier 2013-01-12 13:38 ` Leo Liu 2013-01-12 13:52 ` Eli Zaretskii 0 siblings, 2 replies; 20+ messages in thread From: Stefan Monnier @ 2013-01-12 13:08 UTC (permalink / raw) To: Leo Liu; +Cc: emacs-devel >> 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to debug Error during redisplay 2013-01-12 13:08 ` Stefan Monnier @ 2013-01-12 13:38 ` Leo Liu 2013-01-12 13:52 ` Eli Zaretskii 1 sibling, 0 replies; 20+ messages in thread From: Leo Liu @ 2013-01-12 13:38 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to debug Error during redisplay 2013-01-12 13:08 ` Stefan Monnier 2013-01-12 13:38 ` Leo Liu @ 2013-01-12 13:52 ` Eli Zaretskii 2013-01-12 14:07 ` Leo Liu 2013-01-12 14:38 ` Stefan Monnier 1 sibling, 2 replies; 20+ messages in thread From: Eli Zaretskii @ 2013-01-12 13:52 UTC (permalink / raw) To: Stefan Monnier; +Cc: sdl.web, emacs-devel > 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to debug Error during redisplay 2013-01-12 13:52 ` Eli Zaretskii @ 2013-01-12 14:07 ` Leo Liu 2013-01-12 14:38 ` Stefan Monnier 1 sibling, 0 replies; 20+ messages in thread From: Leo Liu @ 2013-01-12 14:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Stefan Monnier, emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to debug Error during redisplay 2013-01-12 13:52 ` Eli Zaretskii 2013-01-12 14:07 ` Leo Liu @ 2013-01-12 14:38 ` Stefan Monnier 1 sibling, 0 replies; 20+ messages in thread From: Stefan Monnier @ 2013-01-12 14:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: sdl.web, emacs-devel > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2013-01-12 17:17 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-01-11 9:03 How to debug Error during redisplay Leo Liu 2013-01-11 10:25 ` Eli Zaretskii 2013-01-11 11:02 ` Leo Liu 2013-01-11 14:08 ` Eli Zaretskii 2013-01-12 5:25 ` Leo Liu 2013-01-12 9:43 ` Eli Zaretskii 2013-01-12 11:56 ` Leo Liu 2013-01-12 12:03 ` Leo Liu 2013-01-12 13:49 ` Eli Zaretskii 2013-01-12 13:58 ` Leo Liu 2013-01-12 14:31 ` Eli Zaretskii 2013-01-12 17:17 ` Stephen Berman 2013-01-12 12:30 ` Eli Zaretskii 2013-01-11 14:56 ` Stefan Monnier 2013-01-12 5:26 ` Leo Liu 2013-01-12 13:08 ` Stefan Monnier 2013-01-12 13:38 ` Leo Liu 2013-01-12 13:52 ` Eli Zaretskii 2013-01-12 14:07 ` Leo Liu 2013-01-12 14:38 ` Stefan Monnier
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.