bug#70760: 29.3.50; core dumps when copy in other apps

[Kun Liu]

I did as instructed.

Here is a couple of instances of what I saw in *Messages* right after I was able to trigger the problem.

case 1:

DBus-Event (dbus-event :post-blank 0 :post-affiliated 1455145 :mode nil :granularity element :cached t :parent (section (:begin 1179957 :end 1609350 :contents-begin 1179957 :contents-end 1609349 :robust-begin 1179957 :robust-end 1609347 :post-blank 1 :post-affiliated 1179957 :mode section :granularity element :cached t :parent (headline (:raw-value Old stuff :begin 1179945 :end 1609350 :pre-blank 0 :contents-begin 1179957 :contents-end 1609349 :robust-begin 1180109 :robust-end 1609347 :level 1 :priority nil :tags nil :todo-keyword nil :todo-type nil :post-blank 1 :footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated 1179945 :ARCHIVE_TIME 2020-10-17 Sat 15:00 :ARCHIVE_FILE ~/work/worklog.org :ARCHIVE_OLPATH Scratch :ARCHIVE_CATEGORY worklog :title Old stuff :mode nil :granularity element :cached t :parent (org-data (:begin 1 :contents-begin 1 :contents-end 15432855 :end 15432856 :robust-begin 3 :robust-end 15432853 :post-blank 1 :post-affiliated 1 :path /home/kun/work/worklog.org_archive :mode org-data :CATEGORY worklog :cached t :org-element--cache-sync-key nil)) :org-element--cache-sync-key nil)) :org-element--cache-sync-key nil)) :org-element--cache-sync-key nil) [2 times]
Entering debugger...
DBus-Event (dbus-event x . make4ht)
funcall-interactively: Wrong type argument: listp, "make4ht"

case 2:

DBus-Event (dbus-event :post-blank 0 :post-affiliated 1455145 :mode nil :granularity element :cached t :parent (section (:begin 1179957 :end 1609350 :contents-begin 1179957 :contents-end 1609349 :robust-begin 1179957 :robust-end 1609347 :post-blank 1 :post-affiliated 1179957 :mode section :granularity element :cached t :parent (headline (:raw-value Old stuff :begin 1179945 :end 1609350 :pre-blank 0 :contents-begin 1179957 :contents-end 1609349 :robust-begin 1180109 :robust-end 1609347 :level 1 :priority nil :tags nil :todo-keyword nil :todo-type nil :post-blank 1 :footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated 1179945 :ARCHIVE_TIME 2020-10-17 Sat 15:00 :ARCHIVE_FILE ~/work/worklog.org :ARCHIVE_OLPATH Scratch :ARCHIVE_CATEGORY worklog :title Old stuff :mode nil :granularity element :cached t :parent (org-data (:begin 1 :contents-begin 1 :contents-end 15432855 :end 15432856 :robust-begin 3 :robust-end 15432853 :post-blank 1 :post-affiliated 1 :path /home/kun/work/worklog.org_archive :mode org-data :CATEGORY worklog :cached t :org-element--cache-sync-key nil)) :org-element--cache-sync-key nil)) :org-element--cache-sync-key nil)) :org-element--cache-sync-key nil) [2 times]
dbus-event-bus-name: D-Bus error: "Not a valid D-Bus event", (dbus-event :post-blank 0 :post-affiliated 1455145 :mode nil :granularity element :cached ...)

On Wed, May 15, 2024 at 3:35 AM Michael Albinus <michael.albinus@gmx.de> wrote:

Eli Zaretskii <eliz@gnu.org> writes:

Hi,

> We have already established that some invalid D-Bus events cause these
> problems.  What we need now is to find out what kind of D-Bus events
> are those, and what does VirtualBox mean to happen when it emits these
> D-Bus events?
>
> Looking at dbus-check-event, I see that event of the form
>
>   (dbus-event 10 14)
>
> is invalid because the first member of the list after 'dbus-event'
> should be either a keyword (a symbol, AFAIU) or a string, but here we
> have a number.
>
> The event
>
>   (dbus-event "[ \11]*$")
>
> from your previous message is also invalid, since it has only one
> member after 'dbus-event'.
>
> IOW, VirtualBox is emitting invalid D-Bus events, at least as far as
> our support for D-Bus is concerned.
>
> Michael, are these events invalid according to the D-Bus spec, or we
> just lack support for them in Emacs?  If the former, I don't see how
> this can be an Emacs problem; you should ask the VirtualBox folks what
> to do to avoid this.

These aren't valid D-Bus events according to the spec, and I doubt that
they come from D-Bus itself. But let's instrument Emacs in order to see
which D-Bus events flow around. The following recipe:

--8<---------------cut here---------------start------------->8---
# rm src/dbusbind.o
# make MYCPPFLAGS='-DDBUS_DEBUG'
# src/emacs --eval '(setq dbus-debug t message-log-max t)'
--8<---------------cut here---------------end--------------->8---

Then trigger the problem, and send us the *Messages* buffer afterwards.
Recompile Emacs w/o the MYCPPFLAGS arg.

> Maybe we can make Emacs more tolerant to these issues, e.g., make the
> error a warning or a message?

Maybe. But my gut feeling tells me there is an error in Emacs handling
incoming event. And this isn't related to D-Bus, necessarily.

> All in all, I feel like this is not an Emacs issue at all, and should
> not be brought to us.

Maybe. But I'd like to see the D-Bus events first.

Best regards, Michael.