On Tue, Jul 12, 2016 at 10:02 AM Eli Zaretskii <eliz@gnu.org> 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 <schwab@suse.de> 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.