bug#56162: 13.1.3; "org.freedesktop.DBus.Error.ServiceUnknown" when loading AucTeX

[Michael Albinus]

Tassilo Horn <tsdh@gnu.org> writes:

> Hi Philip & Michael,

Hi Tassilo & Philip,

> it looks more like a TRAMP issue to me, so I added Michael to the Cc.

Yes, it is Tramp.

> So we can assume you have dbus and the session dbus is available.  But
> why does the dbus-ping signal an error?  I can do
>
>   (TeX-evince-dbus-p "foo" "bar")
>
> just fine which simply returns nil.  And how come there's tramp stuff in
> your backtrace and you get a file-error?  And what is
> /home/cip/2017/oj14ozun/.links2 for a file and why is it accessed via
> sftp?
>
> Ah, it seems you have tramp-gvfs-dbus-event-error in
> dbus-event-error-functions which is simply added when tramp-gvfs.el is
> loaded.  But when loading tramp-gvfs, I still cannot trigger the error
> because tramp-gvfs-dbus-event-vector is nil.

We don't need AucTeX and friends for this error :-) A simple scenario is

--8<---------------cut here---------------start------------->8---
# emacs -Q
;; Activatel anything tramp-gvfs.el is responsible for, like
(file-attributes "/sftp::")

=> (t 0 0 0 (25267 48739 0 0) (25259 16295 0 0) (0 0 0 0) 4096 "dr-xr-xr-x" nil 
1 (-1 . 1))

(dbus-ping :session "foo.bar")

=> Debugger entered--Lisp error: (file-error 
"org.freedesktop.DBus.Error.ServiceUnknown")
  signal(file-error ("org.freedesktop.DBus.Error.ServiceUnknown"))
  tramp-error((tramp-file-name "sftp" nil nil #("gandalf" 0 7 (tramp-default 
t)) nil "/" nil) file-error "org.freedesktop.DBus.Error.ServiceUnknown")
  tramp-gvfs-dbus-event-error((dbus-event :session 3 48 "org.freedesktop.DBus" 
":1.220203" nil nil "org.freedesktop.DBus.Error.ServiceUnknown" 
dbus-call-method-handler (:string "The name is not activatable")) (dbus-error 
"org.freedesktop.DBus.Error.ServiceUnknown" "The name is not activatable"))
  run-hook-with-args(tramp-gvfs-dbus-event-error (dbus-event :session 3 48 
"org.freedesktop.DBus" ":1.220203" nil nil 
"org.freedesktop.DBus.Error.ServiceUnknown" dbus-call-method-handler (:string 
"The name is not activatable")) (dbus-error 
"org.freedesktop.DBus.Error.ServiceUnknown" "The name is not activatable"))
  dbus-handle-event((dbus-event :session 3 48 "org.freedesktop.DBus" 
":1.220203" nil nil "org.freedesktop.DBus.Error.ServiceUnknown" 
dbus-call-method-handler (:string "The name is not activatable")))
  funcall-interactively(dbus-handle-event (dbus-event :session 3 48 
"org.freedesktop.DBus" ":1.220203" nil nil 
"org.freedesktop.DBus.Error.ServiceUnknown" dbus-call-method-handler (:string 
"The name is not activatable")))
  call-interactively(dbus-handle-event nil [(dbus-event :session 3 48 
"org.freedesktop.DBus" ":1.220203" nil nil 
"org.freedesktop.DBus.Error.ServiceUnknown" dbus-call-method-handler (:string 
"The name is not activatable"))])
  command-execute(dbus-handle-event nil [(dbus-event :session 3 48 
"org.freedesktop.DBus" ":1.220203" nil nil 
"org.freedesktop.DBus.Error.ServiceUnknown" dbus-call-method-handler (:string 
"The name is not activatable"))] t)
  read-event(nil nil 0.001)
  dbus-call-method(:session "foo.bar" "/org/freedesktop/DBus" 
"org.freedesktop.DBus.Peer" "Ping")
  dbus-ping(:session "foo.bar")
--8<---------------cut here---------------end--------------->8---

> Philip, you got that backtrace from M-x TeX-submit-bug-report.  Where
> did that /home/cip/2017/oj14ozun/.links2 file come from in that context?

That is not relevant.

> And Michael, looking at the code I have the feeling that
> tramp-gvfs-dbus-event-vector should be buffer-local but it's set
> globally and then causes the issue...

Somehow. tramp-gvfs tries to catch *any* D-Bus error it sees, even if it
isn't responsible for. And from the error itself it cannot determine
whether it is meant for tramp-gvfs, the struct

--8<---------------cut here---------------start------------->8---
(dbus-event :session 3 48 "org.freedesktop.DBus" ":1.220203" nil nil 
"org.freedesktop.DBus.Error.ServiceUnknown" dbus-call-method-handler (:string 
"The name is not activatable"))
--8<---------------cut here---------------end--------------->8---

tells us that it is an error ("3") with the serial "48" (not relevant,
D-Bus internal counter) from service "org.freedesktop.DBus" (the general
purpose D-Bus service) sent to service ":1.220203" (that's us,
Emacs). So there is no chance to filter tramp-gvfs events out.

A buffer-local tramp-gvfs-dbus-event-vector doesn't help; the D-Bus
event is received asynchronously, and it can happen any time Emacs reads
incoming events. No guarantee that the respective buffer is current.

The appended patch changes tramp-gvfs-dbus-event-vector being let-bound
while tramp-gvfs is in action. There is the possible threat that a
related D-Bus event arrives too late, due to time-outs or so, but let's
see how it works.

Could you pls check the patch?

> Bye,
> Tassilo

Best regards, Michael.

txtcypyVAVRK6.txt
Description: Text Data