search

altdesktop / python-dbus-next

🚌 The next great DBus library for Python with asyncio support
https://python-dbus-next.readthedocs.io/en/latest/
MIT License
187 stars 58 forks source link

glib: destroy the _AuthLineSource explicitly #114

Closed whot closed 1 year ago

whot commented 2 years ago

See https://gitlab.gnome.org/GNOME/pygobject/-/issues/525 for an explanation, the summary is: we need to explicitly call source.destroy() if dispatch returns GLib.SOURCE_REMOVE.

Deleting the source by resetting it to None causes invalid memory accesses and eventual crashes.

This can be reproduced with a basic call to

    bus = dbus_next.glib.MessageBus(bus_type=dbus_next.BusType.SESSION).connect_sync()

and a GLib.MainLoop() after this call. Run in valgrind --tool=memcheck.

Fixes #113

acrisci commented 1 year ago

:+1:

Consolatis commented 3 months ago

When I understand the linked issue correctly, shouldn't dbus-next destroy *all* sources whenever they return GLib.SOURCE_REMOVE (e.g. what is called Option a in the linked issue)? That seems also way easier compared to what is called Option b in the issue, e.g. destroying it in the callbacks.

Side-note: all versions of Debian are affected by the issue, likely due to there not being a release since this fix.

whot commented 3 months ago

fwiw, I have virtually no recollection of the specifics of this bug but I think this bug may have been specific to subclassing GLib.Source. But that's a very vague guess after all this time.

Consolatis commented 3 months ago

I think this bug may have been specific to subclassing GLib.Source

Thanks for your comment. Right, should have been more specific in the earlier comment. That is what I was referring to (there are at least 3 GLib.Source subclasses in message_bus.py).

Anyway, this project seems dead and apparently dbus-fast didn't cherry-pick the fix either. I guess another python dbus lib bites the dust. Which is a bit sad as the asyncio part here seems to work great and I really like the API. But with it potentially segfaulting depending on the version packaged (e.g. way more likely to segfault than not) I can't use it with GTK.

whot commented 3 months ago

hmm, yeah, that makes sense though I probably didn't trigger this back then, so... :shrug: