Openning a connection to a separate D-BUS bus

[ydirson]

Although the README says we can create a ravel.Connection object, this is discouraged in the class' docstring.

The AT-SPI accessibility system uses a separate bus, which we can get eg. with:

ravel.session_bus()["org.a11y.Bus"]["/org/a11y/bus"]. get_interface("org.a11y.Bus").GetAddress()

This returns a string (well, a 1-element string list, which surprises the dbussy-noob in me) suitable for eg. qdbus --bus .....

Trying to use it with ravel, on Debian/testing (dbussy 1.3):

(gdb) r
Starting program: /usr/bin/python3 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Python 3.9.2 (default, Feb 28 2021, 17:03:44) 
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ravel, dbussy
>>> dc = dbussy.Connection("unix:abstract=/tmp/dbus-OKvAHab7BF,guid=16dcea406b353b040999d5dc607c652e")
>>> c = ravel.Connection(dc)

Program received signal SIGSEGV, Segmentation fault.
__GI___pthread_mutex_lock (mutex=0x4600000042) at ../nptl/pthread_mutex_lock.c:67
67      ../nptl/pthread_mutex_lock.c: Aucun fichier ou dossier de ce type.
#0  __GI___pthread_mutex_lock (mutex=0x4600000042) at ../nptl/pthread_mutex_lock.c:67
#1  0x00007ffff6bbc422 in dbus_connection_get_data () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#2  0x00007ffff6bb5269 in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#3  0x00007ffff6bb5d08 in dbus_bus_get_unique_name () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#4  0x00007ffff77e2d1d in ?? () from /lib/x86_64-linux-gnu/libffi.so.7
#5  0x00007ffff77e2289 in ?? () from /lib/x86_64-linux-gnu/libffi.so.7
#6  0x00007ffff6f21360 in ?? () from /usr/lib/python3.9/lib-dynload/_ctypes.cpython-39-x86_64-linux-gnu.so
#7  0x00007ffff6f20e05 in ?? () from /usr/lib/python3.9/lib-dynload/_ctypes.cpython-39-x86_64-linux-gnu.so
#8  0x000000000051d89b in _PyObject_MakeTpCall ()
#9  0x00000000005175ba in _PyEval_EvalFrameDefault ()
#10 0x0000000000528b63 in _PyFunction_Vectorcall ()
#11 0x0000000000538d46 in ?? ()
#12 0x0000000000526f68 in _PyObject_GenericGetAttrWithDict ()
#13 0x0000000000511ed1 in _PyEval_EvalFrameDefault ()
#14 0x00000000005106ed in ?? ()
#15 0x0000000000528d21 in _PyFunction_Vectorcall ()
#16 0x0000000000572306 in ?? ()
#17 0x000000000051d686 in _PyObject_MakeTpCall ()
#18 0x00000000005175ba in _PyEval_EvalFrameDefault ()
#19 0x00000000005106ed in ?? ()
#20 0x0000000000510497 in _PyEval_EvalCodeWithName ()
#21 0x00000000005f5be3 in PyEval_EvalCode ()
#22 0x0000000000619de7 in ?? ()
#23 0x0000000000615610 in ?? ()
#24 0x0000000000459cb3 in ?? ()
#25 0x0000000000459911 in PyRun_InteractiveLoopFlags ()
#26 0x00000000006194f5 in PyRun_AnyFileExFlags ()
#27 0x000000000044bca9 in ?? ()
#28 0x00000000005ea6e9 in Py_BytesMain ()
#29 0x00007ffff7c4bd0a in __libc_start_main (main=0x5ea6b0, argc=1, argv=0x7fffffffdb48, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdb38)
    at ../csu/libc-start.c:308
#30 0x00000000005ea5ea in _start ()

Given the ctypes in the backtrace it could be linked to #15, but that one is 100% reproducible.

[ldo]

If you want to connect to a server that does not go through the D-Bus daemon, use the Ravel connect_server/connect_server_async calls. There is an example of this in my dbussy_examples repo. Also, libdbus and threading do not mix very well. Keep your use of threading strictly controlled, as in this example, or avoid completely.

[ydirson]

That does not seem to work out of the box:

Traceback (most recent call last):
  File "/home/yann/perso/omaha/uitest/./atspi-dbussy.py", line 15, in <module>
    conn = ravel.connect_server(address=a11y_busname, private=True)
  File "/usr/lib/python3/dist-packages/ravel.py", line 1510, in connect_server
    Connection(dbus.Connection.open(address, private = False)) \
  File "/usr/lib/python3/dist-packages/ravel.py", line 230, in __new__
    assert unique_name != None, "connection not yet registered"
AssertionError: connection not yet registered

Now this really looks like the problem that lead lrusak write this - and I noticed he also has another patch which seems to deal with another related issue.

Keep your use of threading strictly controlled, as in this example, or avoid completely.

Not sure why you're mentionning this, I'm not using any theading here.

Also, don't you want to keep the ticket open for the segfault ?