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.

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.

Previous Next

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