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

[Kun Liu]

Thanks much, Michael, for the detailed explanation.

I spent more time on this issue. I watched closely both "dbus-monitor --system" and "dbus-monitor" outputs, while trying to replicate the issue in Emacs. It appears that just as you said, when Emacs reported invalid dbus events, which crashes Emacs sometimes, dbus-monitor outputs never showed any messages immediately preceding or following the error.

Which really begs the question, if dbus did not have any messages for Emacs at the time, why did Emacs think there was a message for it?

On Thu, May 16, 2024 at 2:20 AM Michael Albinus <michael.albinus@gmx.de> wrote:

Kun Liu <kun.liu@gmail.com> writes:

Hi,

> I started dbus-monitor to monitor both session and system messages.
> Then I repeated the test mentioned in the last message.
>
> The relevant lines in the "dbus-monitor --system" output: (please note
> that the dbus address is different from the previous test)

Yep. Emacs gets a new D-Bus address every new start, it is :1.82 this
case.

> method call time=1715806663.121956 sender=:1.82 ->
> destination=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus;
> interface=org.freedesktop.DBus; member=Hello
> method return time=1715806663.121973 sender=org.freedesktop.DBus ->
> destination=:1.82 serial=1 reply_serial=1
>    string ":1.82"

Emacs sys "Hello" to D-Bus.

> signal time=1715806663.121976 sender=org.freedesktop.DBus ->
> destination=(null destination) serial=101 path=/org/freedesktop/DBus;
> interface=org.freedesktop.DBus; member=NameOwnerChanged
>    string ":1.82"
>    string ""
>    string ":1.82"
> signal time=1715806663.121981 sender=org.freedesktop.DBus ->
> destination=:1.82 serial=2 path=/org/freedesktop/DBus;
> interface=org.freedesktop.DBus; member=NameAcquired
>    string ":1.82"

D-Bus replies two signals, saying that it understood the "Hello", and
that it has registered the service with unique name :1.82.

> method call time=1715806663.130182 sender=:1.82 ->
> destination=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus;
> interface=org.freedesktop.DBus; member=AddMatch
>    string
> "type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'"
>
> method return time=1715806663.130202 sender=org.freedesktop.DBus ->
> destination=:1.82 serial=3 reply_serial=2

Emacs registers for signals.

> ...
> signal time=1715806675.545929 sender=org.freedesktop.DBus ->
> destination=:1.82 serial=4 path=/org/freedesktop/DBus;
> interface=org.freedesktop.DBus; member=NameLost
>    string ":1.82"
> signal time=1715806675.545978 sender=org.freedesktop.DBus ->
> destination=(null destination) serial=102 path=/org/freedesktop/DBus;
> interface=org.freedesktop.DBus; member=NameOwnerChanged
>    string ":1.82"
>    string ":1.82"
>    string ""

This is very likely the time you have stopped Emacs, and D-Bus
unregisters its unique name, therefore.

> The relevant lines in the "dbus-monitor" output:

The look very similar to the system bus output. Here, Emacs has the
unique name :1.177.

> method call time=1715806663.132256 sender=:1.153 ->
> destination=org.freedesktop.DBus serial=657
> path=/org/freedesktop/DBus; interface=org.freedesktop.DBus;
> member=GetConnectionUnixProcessID
>    string ":1.177"

This is an additional call from service 1.153, which wants to know the
Emacs pid. We can ignore it.

Everything normal, and not related to the problem I believe.

Best regards, Michael.