all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Kaushal Modi <kaushal.modi@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>,
	Stefan Monnier <monnier@iro.umontreal.ca>,
	schwab@suse.de
Cc: 23949@debbugs.gnu.org
Subject: bug#23949: 25.0.95; Regression in handling error caused by (string-match-p "." nil)
Date: Tue, 12 Jul 2016 18:35:02 +0000	[thread overview]
Message-ID: <CAFyQvY03ZV-JZo7B01N=ButamUksfkwqDaiepoTTXovxPkmsaw@mail.gmail.com> (raw)
In-Reply-To: <83h9bvarb6.fsf@gnu.org>

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

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.
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 18386 bytes --]

  reply	other threads:[~2016-07-12 18:35 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-06  1:56 bug#24166: With --eval, errors in string-match-p do not produce backtraces (but errors in string-match do?!) Clément Pit--Claudel
2016-08-06  2:15 ` npostavs
2016-08-06  3:03   ` Clément Pit--Claudel
2016-08-06  7:25   ` Eli Zaretskii
2016-08-06 10:28     ` Noam Postavsky
2016-08-06 10:34       ` Eli Zaretskii
2016-08-06 10:49         ` Noam Postavsky
2016-08-06 11:19           ` Eli Zaretskii
2016-08-06 12:25             ` npostavs
2016-08-07 14:12               ` Eli Zaretskii
2016-08-07 14:27                 ` npostavs
2016-07-11 20:12                   ` bug#23949: 25.0.95; Regression in handling error caused by (string-match-p "." nil) Kaushal Modi
2016-07-12 12:29                     ` Kaushal Modi
2016-07-12 13:14                       ` Eli Zaretskii
2016-07-12 13:33                         ` Kaushal Modi
2016-07-12 13:37                           ` Kaushal Modi
2016-07-12 14:03                             ` Eli Zaretskii
2016-07-12 14:01                           ` Eli Zaretskii
2016-07-12 18:35                             ` Kaushal Modi [this message]
2016-07-12 18:55                               ` Noam Postavsky
2016-07-12 19:00                                 ` Kaushal Modi
2016-07-12 19:12                                   ` Eli Zaretskii
2016-07-12 19:10                               ` Eli Zaretskii
2016-07-12 19:19                               ` Eli Zaretskii
2016-07-12 19:29                                 ` Kaushal Modi
2016-07-12 20:27                               ` Stefan Monnier
2016-07-13 13:10                                 ` Kaushal Modi
2016-07-13 13:59                                   ` Stefan Monnier
2016-07-13 15:06                                     ` Eli Zaretskii
2016-07-13 15:03                                   ` Eli Zaretskii
2016-07-13 14:24                                 ` Eli Zaretskii
2016-07-13 14:48                                   ` Stefan Monnier
2016-07-13 15:14                                     ` Eli Zaretskii
2016-07-13 16:00                                       ` Stefan Monnier
2016-07-13 16:18                                         ` Eli Zaretskii
2016-07-13 16:41                                           ` Stefan Monnier
2016-07-13 15:03                                   ` Andreas Schwab
2016-07-13 15:17                                     ` Eli Zaretskii
2016-07-12 14:15                           ` Andreas Schwab
     [not found]                     ` <handler.23949.C.147058007223290.notifdonectrl.2@debbugs.gnu.org>
2016-08-09 15:56                       ` bug#23949: acknowledged by developer (Re: bug#24166: With --eval, errors in string-match-p do not produce backtraces (but errors in string-match do?!)) Kaushal Modi
2016-08-07 15:43                   ` bug#24166: With --eval, errors in string-match-p do not produce backtraces (but errors in string-match do?!) Clément Pit--Claudel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFyQvY03ZV-JZo7B01N=ButamUksfkwqDaiepoTTXovxPkmsaw@mail.gmail.com' \
    --to=kaushal.modi@gmail.com \
    --cc=23949@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=schwab@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.