GNU bug report logs - #29450
26.0.90; No check for nil in some filenotify functions

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29450 in the body.
You can then email your comments to 29450 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "John Wiegley" <johnw <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.90; No check for nil in some filenotify functions
Date: Sat, 25 Nov 2017 22:18:07 -0800

The documentation for find-file-name-handler says:

    find-file-name-handler is a built-in function in ‘C source code’.
    
    (find-file-name-handler FILENAME OPERATION)
    
    Return FILENAME’s handler function for OPERATION, if it has one.
    Otherwise, return nil.

However, several of the functions in filenotify use the return value of this
function without checking if it's nil or not:

    (defun file-notify-rm-watch (descriptor)
      "Remove an existing watch specified by its DESCRIPTOR.
    DESCRIPTOR should be an object returned by `file-notify-add-watch'."
      (when-let* ((watch (gethash descriptor file-notify-descriptors)))
        (let ((handler (find-file-name-handler
                        (file-notify--watch-directory watch)
                        'file-notify-rm-watch)))
          (condition-case nil
              (if handler
                  ;; A file name handler could exist even if there is no
                  ;; local file notification support.
                  (funcall handler 'file-notify-rm-watch descriptor)

I've been getting several errors with a backtrace like nil(48). This is likely
because some package has done something wrong, but even still, filenotify
should be more defensive.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "John Wiegley" <johnw <at> gnu.org>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#29450: 26.0.90; No check for nil in some filenotify functions
Date: Sun, 26 Nov 2017 17:39:31 +0200

> From: "John Wiegley" <johnw <at> gnu.org>
> Date: Sat, 25 Nov 2017 22:18:07 -0800
> 
> The documentation for find-file-name-handler says:
> 
>     find-file-name-handler is a built-in function in ‘C source code’.
>     
>     (find-file-name-handler FILENAME OPERATION)
>     
>     Return FILENAME’s handler function for OPERATION, if it has one.
>     Otherwise, return nil.
> 
> However, several of the functions in filenotify use the return value of this
> function without checking if it's nil or not:

Maybe I'm blind, but I cannot find any place in filenotify where the
handler is used without checking, including in the case you show:

>     (defun file-notify-rm-watch (descriptor)
>       "Remove an existing watch specified by its DESCRIPTOR.
>     DESCRIPTOR should be an object returned by `file-notify-add-watch'."
>       (when-let* ((watch (gethash descriptor file-notify-descriptors)))
>         (let ((handler (find-file-name-handler
>                         (file-notify--watch-directory watch)
>                         'file-notify-rm-watch)))
>           (condition-case nil
>               (if handler <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>                   ;; A file name handler could exist even if there is no
>                   ;; local file notification support.
>                   (funcall handler 'file-notify-rm-watch descriptor)

What am I missing?

> I've been getting several errors with a backtrace like nil(48). This is likely
> because some package has done something wrong, but even still, filenotify
> should be more defensive.

Can you show a full backtrace like that?

Message #11 received at 29450 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: "John Wiegley" <johnw <at> gnu.org>,  29450 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#29450: 26.0.90; No check for nil in some filenotify functions
Date: Tue, 09 Jan 2018 19:28:52 -0500

Eli Zaretskii wrote:

>> From: "John Wiegley" <johnw <at> gnu.org>
>> Date: Sat, 25 Nov 2017 22:18:07 -0800
>> 
>> The documentation for find-file-name-handler says:
>> 
>>     find-file-name-handler is a built-in function in ‘C source code’.
>>     
>>     (find-file-name-handler FILENAME OPERATION)
>>     
>>     Return FILENAME’s handler function for OPERATION, if it has one.
>>     Otherwise, return nil.
>> 
>> However, several of the functions in filenotify use the return value of this
>> function without checking if it's nil or not:
>
> Maybe I'm blind, but I cannot find any place in filenotify where the
> handler is used without checking, including in the case you show:
>
>>     (defun file-notify-rm-watch (descriptor)
>>       "Remove an existing watch specified by its DESCRIPTOR.
>>     DESCRIPTOR should be an object returned by `file-notify-add-watch'."
>>       (when-let* ((watch (gethash descriptor file-notify-descriptors)))
>>         (let ((handler (find-file-name-handler
>>                         (file-notify--watch-directory watch)
>>                         'file-notify-rm-watch)))
>>           (condition-case nil
>>               (if handler <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>                   ;; A file name handler could exist even if there is no
>>                   ;; local file notification support.
>>                   (funcall handler 'file-notify-rm-watch descriptor)
>
> What am I missing?
>
>> I've been getting several errors with a backtrace like nil(48). This is likely
>> because some package has done something wrong, but even still, filenotify
>> should be more defensive.
>
> Can you show a full backtrace like that?


Any update?

Message #14 received at 29450 <at> debbugs.gnu.org (full text, mbox):

From: John Wiegley <johnw <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 29450 <at> debbugs.gnu.org
Subject: Re: bug#29450: 26.0.90; No check for nil in some filenotify functions
Date: Wed, 10 Jan 2018 15:56:13 -0800

>>>>> "GM" == Glenn Morris <rgm <at> gnu.org> writes:

>>> I've been getting several errors with a backtrace like nil(48). This is
>>> likely because some package has done something wrong, but even still,
>>> filenotify should be more defensive.
>> 
>> Can you show a full backtrace like that?

GM> Any update?

I worked around this with (setq auto-revert-use-notify nil). If it doesn't
happen for anyone else, you can close it. I'll look into it again if I ever
decide to re-enable this.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Message #17 received at 29450 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: John Wiegley <johnw <at> gnu.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 29450 <at> debbugs.gnu.org
Subject: Re: bug#29450: 26.0.90; No check for nil in some filenotify functions
Date: Thu, 11 Jan 2018 10:13:11 +0100

John Wiegley <johnw <at> gnu.org> writes:

Hi,

Sorry to jump in such late; I've overlooked this thread before.

>>>> I've been getting several errors with a backtrace like nil(48). This is
>>>> likely because some package has done something wrong, but even still,
>>>> filenotify should be more defensive.
>>> 
>>> Can you show a full backtrace like that?
>
> I worked around this with (setq auto-revert-use-notify nil). If it doesn't
> happen for anyone else, you can close it. I'll look into it again if I ever
> decide to re-enable this.

I still would like to see a full backtrace. You have quoted

--8<---------------cut here---------------start------------->8---
      (when-let* ((watch (gethash descriptor file-notify-descriptors)))
        (let ((handler (find-file-name-handler
                        (file-notify--watch-directory watch)
                        'file-notify-rm-watch)))
 --8<---------------cut here---------------end--------------->8---

I have the feeling that it isn't the return value of
`find-file-name-handler' being nil, but rather the
`file-notify--watch-directory' call.

Best regards, Michael.

Message #22 received at 29450 <at> debbugs.gnu.org (full text, mbox):

From: John Wiegley <johnw <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Glenn Morris <rgm <at> gnu.org>, 29450 <at> debbugs.gnu.org
Subject: Re: bug#29450: 26.0.90; No check for nil in some filenotify functions
Date: Sun, 04 Feb 2018 22:48:39 -0800

>>>>> "MA" == Michael Albinus <michael.albinus <at> gmx.de> writes:

MA> I have the feeling that it isn't the return value of
MA> `find-file-name-handler' being nil, but rather the
MA> `file-notify--watch-directory' call.

I've had file-notify back on for a few days now, and this has not happened
again, so I'm fine with closing this issue.

However -- and this is a separate bug -- I had to disable it again because it
was stalling out Emacs regularly. I'd ran an operation that changed the state
of the disk, and then Emacs would be locked up for minutes at a time until I
hit C-g repeatedly. Finally, I ran Instruments to see what was going on, and
it was stuck in a busy loop reading directories, spending 92% of its time
calling delq over and over again.

But that's a separate issue, and disabling file-notify cured the performance
problem.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Message #27 received at 29450-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: John Wiegley <johnw <at> gnu.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 29450-done <at> debbugs.gnu.org
Subject: Re: bug#29450: 26.0.90; No check for nil in some filenotify functions
Date: Mon, 05 Feb 2018 08:45:27 +0100

John Wiegley <johnw <at> gnu.org> writes:

Hi John,

> I've had file-notify back on for a few days now, and this has not happened
> again, so I'm fine with closing this issue.

I do it herewith.

> However -- and this is a separate bug -- I had to disable it again because it
> was stalling out Emacs regularly. I'd ran an operation that changed the state
> of the disk, and then Emacs would be locked up for minutes at a time until I
> hit C-g repeatedly. Finally, I ran Instruments to see what was going on, and
> it was stuck in a busy loop reading directories, spending 92% of its time
> calling delq over and over again.

In function `file-notify-handle-event', there's a commented `message'
call. Could you enable this, and send the output when this problem
happens, again?

> But that's a separate issue, and disabling file-notify cured the performance
> problem.

Do you write another bug report for this?

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.