On Tue, Jul 12, 2016 at 10:02 AM Eli Zaretskii wrote: > string-match-p just signals an error, because its 2nd arg must be a > string. Look up the backtrace, and you will see that Emacs is trying > to signal an error: > Correct, but that error does not show up within emacs. All the user sees is: Entering debugger... help-function-arglist: End of file during parsing In any case, I believe that that should not happen. Also concerning is the fact that, - (string-match "." nil) gives the expected error backtrace. - But (string-match-p "." nil) gives the help-function-arglist error. What happens next is that Emacs calls the debugger, and then your > advices kick in, starting at apply1. And that's where the trouble > begins. > Correct. That's exactly what I do not understand. > I asked why help-function-arglist is trying to read from a string, but > got no answer. > Sorry, I missed answering that question in my earlier emails; I got too busy with gdb. I do not have answer for that question. I filed this bug report to learn why this happens, and help in any way I can to fix it. From the below: > "help-function-arglist" (0xffff3f88) > "ad-arglist" (0xffff44c0) > "ad-make-advised-definition" (0xffff4a70) > "ad-activate-advised-definition" (0xffff4fc0) > "ad-activate" (0xffff5500) > "projectile-mode" (0xffff5a50) , the advices in the projectile package are causing this. I grepped the projectile source, and it contains only 2 advices. (1) (defadvice compilation-find-file (around projectile-compilation-find-file) "Try to find a buffer for FILENAME, if we cannot find it, fallback to the original function." (let ((filename (ad-get-arg 1))) (ad-set-arg 1 (or (if (file-exists-p (expand-file-name filename)) filename) ;; Try to find the filename using projectile (and (projectile-project-p) (let ((root (projectile-project-root)) (dirs (cons "" (projectile-current-project-dirs)))) (-when-let (full-filename (->> dirs (--map (expand-file-name filename (expand-file-name it root))) (-filter #'file-exists-p) (-first-item))) full-filename))) ;; Fall back to the old argument filename)) ad-do-it)) (2) (defadvice delete-file (before purge-from-projectile-cache (filename &optional trash)) (if (and projectile-enable-caching (projectile-project-p)) (let* ((project-root (projectile-project-root)) (true-filename (file-truename filename)) (relative-filename (file-relative-name true-filename project-root))) (if (projectile-file-cached-p relative-filename project-root) (projectile-purge-file-from-cache relative-filename))))) As I started using advices only after emacs 24.4, I never learned the old advice style. So I hoped someone experienced with these would help connect the dots between invalid arg error for string-match-p and help-function-arglist error. @Stefan? Also, with the exact same projectile version, I do *not* get the misleading help-function-arglist error on emacs 24.5. So something probably changed in the way major mode hooks are run in the debugger since then? Sorry, I see no bug yet, just a lot of ad-FOO stuff that tries to do > something silly during an error, when it should have moved out of the > way. If there is a bug, its root cause hides inside > help-function-arglist, Copying Stefan to help throw some light on this. > and the way it is called by the advices you (or > maybe it's Projectile?) have set up. The minimal code I posted was run in emacs -Q. So the only effective advices are the ones in Projectile; I have pasted the code for those 2 advices above for reference. > That's where we should be > looking, not in string-match-p, which did what it was supposed to do: > signaled an error when called with nil instead of a string. > But then it would be interesting to know why (string-match "." nil) instead does not cause the help-function-arglist error. Here is the backtrace on evaluating ===== (emacs-q-template '(projectile) (projectile-global-mode) (string-match-p "." nil)) ===== (Code for the emacs-q-template macro is in my previous email in this thread.) Backtrace: ===== Debugger entered--Lisp error: (wrong-type-argument stringp nil) string-match("." nil nil) string-match-p("." nil) (progn (require (quote package)) (setq package-user-dir (concat ... eval((progn (require (quote package)) (setq package-user-dir (concat ... eval-last-sexp-1(nil) eval-last-sexp(nil) call-interactively(eval-last-sexp nil nil) command-execute(eval-last-sexp) ===== (I do not get this backtrace in emacs 25.x; above is from emacs 24.5.) And here is the backtrace for evaluating the same when using string-match instead of string-match-p in emacs 24.5: ===== (emacs-q-template '(projectile) (projectile-global-mode) (string-match "." nil)) ===== Backtrace: ===== Debugger entered--Lisp error: (wrong-type-argument stringp nil) string-match("." nil) (progn (require (quote package)) (setq package-user-dir (concat ... eval((progn (require (quote package)) (setq package-user-dir (concat ... eval-last-sexp-1(nil) eval-last-sexp(nil) call-interactively(eval-last-sexp nil nil) command-execute(eval-last-sexp) ===== In the former case, it was string-match("." nil nil) In the latter case, it was, string-match("." nil) Do those 2 consecutive 'nil's somehow throw off the debugger/ad-arglist/help-function-arglist in emacs 25.x? On Tue, Jul 12, 2016 at 10:15 AM Andreas Schwab wrote: > > $15 = 54138084 > > (gdb) xstring > > This is only valid if $ is a Lisp_String. Use xtype to find out. > Hi Andreas, Thanks for looking into this bug thread. I have close to 0 experience with gdb. I typed 'xtype' for the same frame and this is what I got: (gdb) xstring $16 = (struct Lisp_String *) 0x33a14e0 "(nilory is relative, it is com" (gdb) xtype Argument to arithmetic operation not a number or boolean. (gdb) I do not know what to make out of that. Let me know if there are any other gdb commands that I can use to give you more helpful debug info. Thanks everyone. -- -- Kaushal Modi