GNU bug report logs - #78712
31.0.50; definition is void in file-notify

Previous Next

To reply to this bug, email your comments to 78712 AT debbugs.gnu.org.
There is no need to reopen the bug first.

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

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

From: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; definition is void in file-notify
Date: Fri, 06 Jun 2025 11:16:44 +0100

I am running into an issue (on MacOS) where a file-watcher gets called with a specific set of actions, which lead to the error

,----
| file-notify--call-handler: Symbol's function definition is void: nil
`----

Here's the full stack trace:

,----
| Debugger entered--Lisp error: (void-function nil)
|   nil((63 attribute-changed "[redacted]"))
|   file-notify--call-handler(#s(file-notify--watch :directory "[redacted]" :filename "[redacted]" :callback nil) 63 attribute-changed "[redacted]" nil)
|   file-notify--handle-event(63 (renamed attribute-changed deleted) "[redacted]" nil)
|   file-notify--callback-kqueue((63 (rename attrib delete) "[redacted]"))
|   file-notify-handle-event((file-notify (63 (rename attrib delete) "[redacted]") file-notify--callback-kqueue))
|   funcall-interactively(file-notify-handle-event (file-notify (63 (rename attrib delete) "[redacted]") file-notify--callback-kqueue))
|   command-execute(file-notify-handle-event nil [(file-notify (63 (rename attrib delete) "[redacted]") file-notify--callback-kqueue)] t)
`----

and here's some code that replicates the error (I can't figure out now to replicate the event itself)

--8<---------------cut here---------------start------------->8---
(let* ((desc (car (hash-table-keys file-notify-descriptors)))
       (watch (gethash desc file-notify-descriptors))
       (action '(rename atttrib delete)))
  (when desc
    (file-notify-handle-event
     (make-file-notify
      :-event (list desc action (file-notify--watch-absolute-filename watch))
      :-callback 'file-notify--callback-kqueue))))
--8<---------------cut here---------------end--------------->8---

assuming that `file-notify-descriptors` has some entries (enabling `global-auto-revert-mode` would add such entries).

The issues seems to be that when processing the first action (`rename`), the function `file-notify--handle-event` treats it as 'delete' which calls `file-notify-rm-watch` which calls `file-notify--rm-descriptor` which has the line `(setf
(file-notify--watch-callback watch) nil)`

This modifies the hash to have a nil handler, which trips up
`file-notify--handle-event` when the actual `delete` event is processed.

The same effect can be seen if the actions are (rename delete) or (delete delete).

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
Cc: 78712 <at> debbugs.gnu.org
Subject: Re: bug#78712: 31.0.50; definition is void in file-notify
Date: Fri, 06 Jun 2025 14:49:49 +0200

Al Haji-Ali <abdo.haji.ali <at> gmail.com> writes:

Hi,

> I am running into an issue (on MacOS) where a file-watcher gets called with a specific set of actions, which lead to the error
>
> ,----
> | file-notify--call-handler: Symbol's function definition is void: nil
> `----
>
> Here's the full stack trace:
>
> ,----
> | Debugger entered--Lisp error: (void-function nil)
> |   nil((63 attribute-changed "[redacted]"))
> |   file-notify--call-handler(#s(file-notify--watch :directory "[redacted]" :filename "[redacted]" :callback nil) 63 attribute-changed "[redacted]" nil)
> |   file-notify--handle-event(63 (renamed attribute-changed deleted) "[redacted]" nil)
> |   file-notify--callback-kqueue((63 (rename attrib delete) "[redacted]"))
> |   file-notify-handle-event((file-notify (63 (rename attrib delete) "[redacted]") file-notify--callback-kqueue))
> |   funcall-interactively(file-notify-handle-event (file-notify (63 (rename attrib delete) "[redacted]") file-notify--callback-kqueue))
> |   command-execute(file-notify-handle-event nil [(file-notify (63 (rename attrib delete) "[redacted]") file-notify--callback-kqueue)] t)
> `----


--8<---------------cut here---------------start------------->8---
> |   file-notify-handle-event((file-notify (63 (rename attrib delete) "[redacted]") file-notify--callback-kqueue))
--8<---------------cut here---------------end--------------->8---

This looks wrong. The event in the object, file-notify-handle-event is
called with, has only three slots: (63 (rename attrib delete) "[redacted]").

There must be 4 slots, like in (tested on my FreeBDS14 VM):

--8<---------------cut here---------------start------------->8---
file-notify-handle-event((file-notify (6 (rename) "xxx" "yyy") file-notify--callback-kqueue))
--8<---------------cut here---------------end--------------->8---

> and here's some code that replicates the error (I can't figure out now to replicate the event itself)
>
> (let* ((desc (car (hash-table-keys file-notify-descriptors)))
>        (watch (gethash desc file-notify-descriptors))
>        (action '(rename atttrib delete)))
>   (when desc
>     (file-notify-handle-event
>      (make-file-notify
>       :-event (list desc action (file-notify--watch-absolute-filename watch))
>       :-callback 'file-notify--callback-kqueue))))
>
> assuming that `file-notify-descriptors` has some entries (enabling `global-auto-revert-mode` would add such entries).

So you must update the :-event slot.

Why do you call file-notify-handle-event yourself? It is not intended
for this use case.

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

From: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 78712 <at> debbugs.gnu.org
Subject: Re: bug#78712: 31.0.50; definition is void in file-notify
Date: Fri, 06 Jun 2025 13:59:08 +0100

On 06/06/2025, Michael Albinus wrote:
>
> --8<---------------cut here---------------start------------->8---
>> |   file-notify-handle-event((file-notify (63 (rename attrib delete) "[redacted]") file-notify--callback-kqueue))
> --8<---------------cut here---------------end--------------->8---
>
> This looks wrong. The event in the object, file-notify-handle-event is
> called with, has only three slots: (63 (rename attrib delete) "[redacted]").
>
> Why do you call file-notify-handle-event yourself? It is not intended
> for this use case.

I am not sure why it's wrong. Happy to debug if given directions.
Note that I do not actually call `file-notify-handle-event` myself. The call-stack I gave is produced regularly yet randomly, on what I suspect are certain changes to the file under question (the file is automatically sync'ed so I don't control the changes).

The code I provided is just something I cobbled together to showcase that the cause of the error is the action sequence (rename attrib delete), which seem to be a legitimate sequence based on the callstack.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
Cc: 78712 <at> debbugs.gnu.org
Subject: Re: bug#78712: 31.0.50; definition is void in file-notify
Date: Fri, 06 Jun 2025 17:40:24 +0200

Al Haji-Ali <abdo.haji.ali <at> gmail.com> writes:

Hi,

> Note that I do not actually call `file-notify-handle-event`
> myself. The call-stack I gave is produced regularly yet randomly, on
> what I suspect are certain changes to the file under question (the
> file is automatically sync'ed so I don't control the changes).
>
> The code I provided is just something I cobbled together to showcase
> that the cause of the error is the action sequence (rename attrib
> delete), which seem to be a legitimate sequence based on the
> callstack.

Well, let's analyze what happens. No artificial test code.

Please set file-notify-debug. We'll see the arrived events then in the
*Message* buffer, like shown in my other message:

--8<---------------cut here---------------start------------->8---
file-notify-handle-event (file-notify (6 (rename) "xxx" "yyy") file-notify--callback-kqueue)
--8<---------------cut here---------------end--------------->8---

Send the event traces.

I'd like also to understand what has triggered the (rename attrib
delete) actions combined in one event. Is it related to an edit action
from yourself, or due to the said sync action? Which kind of sync action
is this?

Does the sync action happen on a mounted file system?

Best regards, Michael.

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

From: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 78712 <at> debbugs.gnu.org
Subject: Re: bug#78712: 31.0.50; definition is void in file-notify
Date: Mon, 09 Jun 2025 09:31:03 +0100

On 06/06/2025, Michael Albinus wrote:
> Well, let's analyze what happens. No artificial test code.

Happy to help with this. Just a couple of notes:
- If the "error" is the bizarre action sequence, while it is regularly re-produced, I don't know the precise conditions for it so I will have to wait until it randomly shows up for any debugging.
- If the action sequence (rename attrib delete) is an expected one, my "artificial" code is just showing that this sequence causes the error to be thrown due to the logic in the code.

> Please set file-notify-debug. We'll see the arrived events then in the
> *Message* buffer, like shown in my other message:
>
> --8<---------------cut here---------------start------------->8---
> file-notify-handle-event (file-notify (6 (rename) "xxx" "yyy") file-notify--callback-kqueue)
> --8<---------------cut here---------------end--------------->8---
>
> Send the event traces.

I got this.

--8<---------------cut here---------------start------------->8---
file-notify-handle-event (file-notify (61 (rename attrib delete) "[redacted-dir]/[redacted-filename]") file-notify--callback-kqueue)
file-notify-callback 61 deleted "[redacted-dir]/[redacted-filename]" nil #s(file-notify--watch "[redacted-dir]" "[redacted-filename]" auto-revert-notify-handler) "[redacted-dir]/[redacted-filename]" "[redacted-dir]"
file-notify-handle-event (file-notify (61 stopped "[redacted-dir]/[redacted-filename]") auto-revert-notify-handler) [2 times]
file-notify-callback 61 attribute-changed "[redacted-dir]/[redacted-filename]" nil #s(file-notify--watch "[redacted-dir]" "[redacted-filename]" nil) "[redacted-dir]/[redacted-filename]" "[redacted-dir]"
file-notify--call-handler: Symbol’s function definition is void: nil
--8<---------------cut here---------------end--------------->8---

Note that while I tested my artificial code on 31.0.50, showing the error being thrown, the log above is reported from my daily Emacs 29.1.
For various reasons I cannot update to the latest version for my daily Emacs and as I mentioned the error happens somewhat randomly, so my only real chance to catch it is in this emacsen. 

> I'd like also to understand what has triggered the (rename attrib
> delete) actions combined in one event. Is it related to an edit action
> from yourself, or due to the said sync action? Which kind of sync action
> is this?
I suspect it is triggered by an action of my automatic sync. This is an iCloud driver on macOS.
I've also seen similar errors on a file in a Dropbox folder (again on macOS).

> Does the sync action happen on a mounted file system?
Yes, the file system should be mounted, I believe. Though I am unclear on the internals of an iCloud drive. 

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
Cc: 78712 <at> debbugs.gnu.org
Subject: Re: bug#78712: 31.0.50; definition is void in file-notify
Date: Mon, 09 Jun 2025 13:47:53 +0200

[Message part 1 (text/plain, inline)]

Al Haji-Ali <abdo.haji.ali <at> gmail.com> writes:

Hi,

> I got this.
>
> file-notify-handle-event (file-notify (61 (rename attrib delete) "[redacted-dir]/[redacted-filename]") file-notify--callback-kqueue)
> file-notify-callback 61 deleted "[redacted-dir]/[redacted-filename]" nil #s(file-notify--watch "[redacted-dir]" "[redacted-filename]" auto-revert-notify-handler) "[redacted-dir]/[redacted-filename]" "[redacted-dir]"
> file-notify-handle-event (file-notify (61 stopped "[redacted-dir]/[redacted-filename]") auto-revert-notify-handler) [2 times]
> file-notify-callback 61 attribute-changed "[redacted-dir]/[redacted-filename]" nil #s(file-notify--watch "[redacted-dir]" "[redacted-filename]" nil) "[redacted-dir]/[redacted-filename]" "[redacted-dir]"
> file-notify--call-handler: Symbol’s function definition is void: nil
>
> Note that while I tested my artificial code on 31.0.50, showing the error being thrown, the log above is reported from my daily Emacs 29.1.
> For various reasons I cannot update to the latest version for my daily Emacs and as I mentioned the error happens somewhat randomly, so my only real chance to catch it is in this emacsen. 

Well, I haven't seen an action list (rename attrib delete) yet, but it
seems to be legitimate use.

I suppose the appended patch should fix it. It is assembled on top of
Emacs 31, but it should also apply on Emacs 29. Do you have a chance to
test it?

Best regards, Michael.

[Message part 2 (text/x-patch, attachment)]

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

From: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 78712 <at> debbugs.gnu.org
Subject: Re: bug#78712: 31.0.50; definition is void in file-notify
Date: Wed, 11 Jun 2025 19:05:13 +0200

On 09/06/2025, Michael Albinus wrote:

> I suppose the appended patch should fix it. It is assembled on top of
> Emacs 31, but it should also apply on Emacs 29. Do you have a chance to
> test it?
I haven't seen the error since applying this patch. So I do think it fixes the issue.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
Cc: 78712-done <at> debbugs.gnu.org
Subject: Re: bug#78712: 31.0.50; definition is void in file-notify
Date: Wed, 11 Jun 2025 19:23:17 +0200

Version: 31.1

Al Haji-Ali <abdo.haji.ali <at> gmail.com> writes:

Hi,

>> I suppose the appended patch should fix it. It is assembled on top of
>> Emacs 31, but it should also apply on Emacs 29. Do you have a chance to
>> test it?
> I haven't seen the error since applying this patch. So I do think it fixes the issue.

Thanks for the feedback. I've pushed it to the master branch, closing
the bug.

Best regards, Michael.

Previous Next

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