hp at redhat.com
Sun Jul 31 11:49:40 EST 2005
On Sat, 2005-07-30 at 18:05 +0200, Lennart Poettering wrote:
> 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 main reason was to test the thread capabilities of libdbus and the
glib bindings. It really should not create much complexity if libdbus
threading works, which is a big "if" of course, but that's the whole
point of testing it ;-)
> 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)
Probably some issue with the dbus-connection.c threading and blocking,
just needs to be debugged. The backtrace doesn't tell me much but maybe
the verbose spew would be helpful.
> 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.
Doubtful. Looking at the code I don't really see why that would break,
probably some simple screwup.
> 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:
> Changes include:
> * 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
If nobody sees a problem with it I'll put it in (I don't know much about
> 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.
Added to the TODO for 1.0. It should be autocopied from CVS, is the
reason it isn't entirely trivial to post this (though it isn't rocket
Thanks for the bug reports.
More information about the dbus