mzqohf at 0pointer.de
Sun Jul 31 02:05:38 EST 2005
I am currently working on adding introspection support to the DBUS
interface of Avahi. I am experiencing some anomalies with dbus-viewer,
probably some kind of race condition.
My DBUS server makes use of the glib main loop but for my DBUS methods
I do not use the gobject stuff. My introspection XML fragments are
rather long, see
for an example.
When run as is, dbus-viewer fails undeterministacally to parse and
show the XML data specified above. No error message is
logged. Sometimes it is able to download and parse the XML data,
sometimes it is not, showing no results, just white space. If I slow
down either the server side or dbus-view with valgrind or strace, it
always succeeds in downloading and parsing the XML data. dbus-send is
always able to download and print the data.
I started to debug dbus-viewer with gdb, but stopped it being annoyed
by the fact that dbus-viewer uses threads (why? is there any good
reason complicating things that much? this only creates bugs to find,
... like this one). the function call
dbus_g_proxy_call() on line 300 of dbus-viewer.c freezes and never
returns. (it doesn't even timeout, as it seems)
#0 0xb79891c3 in poll () from /lib/tls/libc.so.6
#1 0xb7f098fd in _dbus_poll (fds=0xfffffffc, n_fds=-4, timeout_milliseconds=-4) at dbus-sysdeps.c:1879
#2 0xb7f02ce8 in unix_do_iteration (transport=0x8085528, flags=6, timeout_milliseconds=24953) at dbus-transport-unix.c:1021
#3 0xb7f01b3c in _dbus_transport_do_iteration (transport=0x8085528, flags=6, timeout_milliseconds=-4) at dbus-transport.c:715
#4 0xb7eeb8b6 in _dbus_connection_do_iteration_unlocked (connection=0x8085880, flags=6, timeout_milliseconds=24953) at dbus-connection.c:1050
#5 0xb7eed6c8 in _dbus_connection_block_pending_call (pending=0x8134d88) at dbus-connection.c:2619
#6 0xb7efc70f in dbus_pending_call_block (pending=0xfffffffc) at dbus-pending-call.c:310
#7 0xb7f21907 in dbus_g_proxy_end_call_internal (proxy=0x8134900, call_id=1, error=0x8134968, first_arg_type=64, args=0xb74e93e4 "ø\223N·") at dbus-gproxy.c:2098
#8 0xb7f221ae in dbus_g_proxy_call (proxy=0x8134900, method=0xfffffffc <Address 0xfffffffc out of bounds>, error=0xfffffffc, first_arg_type=135481600) at dbus-gproxy.c:2347
#9 0x0804c9d1 in load_from_service_thread_func (thread_data=0x8134960) at dbus-viewer.c:300
#10 0xb7a4aebf in g_static_private_free () from /usr/lib/libglib-2.0.so.0
#11 0xb7a912bb in start_thread () from /lib/tls/libpthread.so.0
#12 0xb799200e in clone () from /lib/tls/libc.so.6
If the introspection data contains a function returning an object path
("o"), dbus-view never shows anything sensible. I don't know if the
problem is related.
BTW: The introspection DTD shipped with DBUS is rather broken, it
judges the introspection data of org.freedesktop.DBus as invalid. I
corrected the DTD to match what the DBUS spec says. Please consider
merging this into upstream:
* don't force an order of the elements of a node and of an interface.
* do not require a "name" attribute on nodes.
* allow multiple arguments and annotations per signal and per property
And please consider making it available as
which is what is advertised in all example introspection XML fragments
and in the data from org.freedesktop.DBus.
This is DBUS 0.35.2.
Lennart Poettering; lennart [at] poettering [dot] de
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.de/lennart/
More information about the dbus