bug#58964: 28.2; `file-notify--handle-event` setting callback function to nil

bug#58964: 28.2; `file-notify--handle-event` setting callback function to nil

[Alejandro Pérez Carballo]

The following minimal configuration can be used to trigger the bug on my
end, replacing “~/tmp/test.el” with a path to a file of your choice:

    (require 'filenotify)
    (require 'autorevert)
    (require 'subr-x)
    (global-auto-revert-mode)
    
    (save-window-excursion
      (find-file "~/tmp/test.el"))

Once that’s loaded, calling this:

    (file-notify--handle-event (car (hash-table-keys file-notify-descriptors)) '(renamed attribute-changed deleted) (expand-file-name "~/tmp/test.el") nil)

gives me an error

    file-notify--call-handler: Symbol’s function definition is void: nil

Here’s the backtrace:

    Debugger entered--Lisp error: (void-function nil)
      nil((18 attribute-changed "/Users/apc/tmp/test.el"))
      file-notify--call-handler(#s(file-notify--watch :directory "/Users/apc/tmp" :filename "test.el" :callback nil) 18 attribute-changed "/Users/apc/tmp/test.el" nil)
      file-notify--handle-event(18 (renamed attribute-changed deleted) "/Users/apc/tmp/test.el" nil)
      (progn (file-notify--handle-event (car (hash-table-keys file-notify-descriptors)) '(renamed attribute-changed deleted) (expand-file-name "~/tmp/test.el") nil))
      eval((progn (file-notify--handle-event (car (hash-table-keys file-notify-descriptors)) '(renamed attribute-changed deleted) (expand-file-name "~/tmp/test.el") nil)) t)
      elisp--eval-last-sexp(nil)
      eval-last-sexp(nil)
      funcall-interactively(eval-last-sexp nil)
      call-interactively(eval-last-sexp nil nil)
      command-execute(eval-last-sexp)

Unfortunately, I cannot figure out at which step is `nil` being passed as the value of `:callback`.

In GNU Emacs 28.2 (build 1, x86_64-apple-darwin21.6.0, NS appkit-2113.60 Version 12.5 (Build 21G72))
 of 2022-09-13 built on APCiMacwork.local
Windowing system distributor 'Apple', version 10.3.2113
System Description:  macOS 12.6

Configured using:
 'configure --disable-dependency-tracking --disable-silent-rules
 --enable-locallisppath=/usr/local/share/emacs/site-lisp
 --infodir=/usr/local/Cellar/emacs-plus@28/28.2/share/info/emacs
 --prefix=/usr/local/Cellar/emacs-plus@28/28.2 --with-xml2 --with-gnutls
 --without-dbus --without-imagemagick --with-modules --with-rsvg
 --with-ns --disable-ns-self-contained 'CFLAGS=-Os -w -pipe
 -march=nehalem -mmacosx-version-min=12
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk'
 'CPPFLAGS=-I/usr/local/opt/icu4c/include
 -I/usr/local/opt/openssl@1.1/include -I/usr/local/opt/readline/include
 -F/usr/local/Frameworks
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk'
 'LDFLAGS=-L/usr/local/opt/icu4c/lib -L/usr/local/opt/openssl@1.1/lib
 -L/usr/local/opt/readline/lib -L/usr/local/lib -F/usr/local/Frameworks
 -Wl,-headerpad_max_install_names
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk''

Configured features:
ACL GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS
PDUMPER PNG RSVG THREADS TIFF TOOLKIT_SCROLL_BARS XIM ZLIB

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/ns-win ns-win ucs-normalize
mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads kqueue cocoa ns lcms2
multi-tty make-network-process emacs)

Memory information:
((conses 16 51202 7299)
 (symbols 48 6554 1)
 (strings 32 18351 1706)
 (string-bytes 1 613349)
 (vectors 16 13830)
 (vector-slots 8 191781 15356)
 (floats 8 21 42)
 (intervals 56 275 0)
 (buffers 992 10))

bug#58964: 28.2; `file-notify--handle-event` setting callback function to nil

[Michael Albinus]

Alejandro Pérez Carballo <apc@umass.edu> writes:

Hi Alejandro,

> The following minimal configuration can be used to trigger the bug on my
> end, replacing “~/tmp/test.el” with a path to a file of your choice:
>
>     (require 'filenotify)
>     (require 'autorevert)
>     (require 'subr-x)
>     (global-auto-revert-mode)
>     
>     (save-window-excursion
>       (find-file "~/tmp/test.el"))
>
> Once that’s loaded, calling this:
>
>     (file-notify--handle-event (car (hash-table-keys file-notify-descriptors)) '(renamed attribute-changed deleted) (expand-file-name "~/tmp/test.el") nil)
>
> gives me an error
>
>     file-notify--call-handler: Symbol’s function definition is void: nil

This is not a valid call of `file-notify--handle-event', see its
docstring how it shall be applied.

Furthermore, this function is an internal one which shouldn't be called
from outside filenotify.el. What's your use case for this?

Best regards, Michael.

bug#58964: 28.2; `file-notify--handle-event` setting callback function to nil

[Alejandro Pérez Carballo]

Hi Michael, 

Thanks for writing back. 

> This is not a valid call of `file-notify--handle-event', see its
> docstring how it shall be applied.

I've looked at the docstring but don't really see why what I gave is not a valid call of the function. 

    Signature
    (file-notify--handle-event DESC ACTIONS FILE FILE1-OR-COOKIE)
    
    Documentation
    Handle an event returned from file notification.
    
    DESC is the back-end descriptor.  ACTIONS is a list of:
     created
     changed
     attribute-changed
     deleted
     renamed           -- FILE is old name, FILE1-OR-COOKIE is new name or nil
     renamed-from      -- FILE is old name, FILE1-OR-COOKIE is cookie or nil
     renamed-to        -- FILE is new name, FILE1-OR-COOKIE is cookie or nil
     stopped           -- no more events after this should be sent


I thought the descriptor would just be one of the keys in the hash table that is the value of `file-notify-descriptors', but maybe I'm misunderstanding how that's all supposed to work. So basically, the call that's giving me the error is this: 

    (file-notify--handle-event 18 '(renamed attribute-changed deleted) "/Users/apc/tmp/test.el" nil)

Is that not a valid call? (I was passing as first argument `(car (hash-table-keys file-notify-descriptors))` because I thought it would be easier to use for reproduction purposes than asking people to see what the key associated with the visited file in `file-notify-descriptors` was.)

As for your other questions: I am not trying to call this function directly, but instead trying to find the source of an error message I've been getting on and off for months. After leaving `debug-on-error' on for a while, I finally got a backtrace. From what I could tell, that was the cause of the trouble. Something in my system is making a call to `file-notify--handle-event' with similar arguments (it was a different file, and a different key, the one that in fact was associated with the file in question in the `file-notify-descriptors` table). 

Unfortunately, I cannot find the original backtrace information. If indeed what I provided was not a valid call of the function, I'll have to wait until next time the error shows up and see if I get more information about what could be making that invalid call in my system. 

Best, 

A.

> On Nov 3, 2022, at 3:46 AM, Michael Albinus <michael.albinus@gmx.de> wrote:
> 
> Alejandro Pérez Carballo <apc@umass.edu> writes:
> 
> Hi Alejandro,
> 
>> The following minimal configuration can be used to trigger the bug on my
>> end, replacing “~/tmp/test.el” with a path to a file of your choice:
>> 
>>    (require 'filenotify)
>>    (require 'autorevert)
>>    (require 'subr-x)
>>    (global-auto-revert-mode)
>> 
>>    (save-window-excursion
>>      (find-file "~/tmp/test.el"))
>> 
>> Once that’s loaded, calling this:
>> 
>>    (file-notify--handle-event (car (hash-table-keys file-notify-descriptors)) '(renamed attribute-changed deleted) (expand-file-name "~/tmp/test.el") nil)
>> 
>> gives me an error
>> 
>>    file-notify--call-handler: Symbol’s function definition is void: nil
> 
> This is not a valid call of `file-notify--handle-event', see its
> docstring how it shall be applied.
> 
> Furthermore, this function is an internal one which shouldn't be called
> from outside filenotify.el. What's your use case for this?
> 
> Best regards, Michael.

bug#58964: 28.2; `file-notify--handle-event` setting callback function to nil

[Michael Albinus]

Alejandro Pérez Carballo <apc@umass.edu> writes:

> Hi Michael, 

Hi Alejandro,

>> This is not a valid call of `file-notify--handle-event', see its
>> docstring how it shall be applied.
>
> I've looked at the docstring but don't really see why what I gave is
> not a valid call of the function.
>
>     Signature
>     (file-notify--handle-event DESC ACTIONS FILE FILE1-OR-COOKIE)
>     
>     Documentation
>     Handle an event returned from file notification.
>     
>     DESC is the back-end descriptor.  ACTIONS is a list of:
>      created
>      changed
>      attribute-changed
>      deleted
>      renamed           -- FILE is old name, FILE1-OR-COOKIE is new name or nil
>      renamed-from      -- FILE is old name, FILE1-OR-COOKIE is cookie or nil
>      renamed-to        -- FILE is new name, FILE1-OR-COOKIE is cookie or nil
>      stopped           -- no more events after this should be sent
>
> I thought the descriptor would just be one of the keys in the hash
> table that is the value of `file-notify-descriptors', but maybe I'm
> misunderstanding how that's all supposed to work. So basically, the
> call that's giving me the error is this:
>
>     (file-notify--handle-event 18 '(renamed attribute-changed deleted) "/Users/apc/tmp/test.el" nil)
>
> Is that not a valid call? (I was passing as first argument `(car
> (hash-table-keys file-notify-descriptors))` because I thought it would
> be easier to use for reproduction purposes than asking people to see
> what the key associated with the visited file in
> `file-notify-descriptors` was.)

There are several problems. It is not clear whether desc 18 is related
to the file name you have given. The combination of actions you have
used is not valid, it makes no sense. When there is a renamed action,
the file1-or-cookie arg must be a file name. And I'm not sure whether we
want to see absolute file names.

Conclusio: Don't mess with this internal function.

> As for your other questions: I am not trying to call this function
> directly, but instead trying to find the source of an error message
> I've been getting on and off for months. After leaving
> `debug-on-error' on for a while, I finally got a backtrace. From what
> I could tell, that was the cause of the trouble. Something in my
> system is making a call to `file-notify--handle-event' with similar
> arguments (it was a different file, and a different key, the one that
> in fact was associated with the file in question in the
> `file-notify-descriptors` table).

For debugging purposes, I recommend to set file-notify-debug to t. This
shall give you a lot of information.

> Unfortunately, I cannot find the original backtrace information. If
> indeed what I provided was not a valid call of the function, I'll have
> to wait until next time the error shows up and see if I get more
> information about what could be making that invalid call in my system.

Yes, please. And if you still cannot determine what's up, pls contact
us. I'm closing *this* bug, because the problem you've reported doesn't
exist as such.

> Best, 
>
> A.

Best regards, Michael.