All quiet on the dbus bus

[Simon Burton]

On Mon, 11 Jan 2010 08:56:14 +0100
Thiago Macieira <thiago at kde.org> wrote:

> Em Segunda-feira 11. Janeiro 2010, às 06.51.07, Simon Burton escreveu:
> > I have my own select loop and put the unix_fd of the dbus connection in
> >  that. After a while (2 hours or so, at several messages per second)
> > my app stops getting any data back from the dbus-daemon, and
> > the select loop goes into a spin.
> 
> What do you mean? There's nothing to be read from the socket?
> 
> Or the app stops writing?
> 
> > In the interests of debugging this I am considering taking over
> >  reading/writing the socket. I am using anonymous connections, but i know
> >  nothing about the auth end of things. Maybe that will be too hard to do
> >  manually.
> > 
> > How do I find out how much dbus data my application is sending/receiving ?
> 
> What for?

So i can answer your previous question, ie. debug my app.

> 
> > It seems that dbus_connection_send always writes immediately (in this app)
> >  so dbus_connection_get_outgoing_size always reports 0.
> 
> Yes, it tries to write immediately. It uses the select(2) write notification 
> only if it couldn't write immediately.
> 
> > It looks like dbus_message_marshal allocates some memory to store the
> >  marshal to. How do I free this memory ?
> 
> What for?

huh?

> 
> The library caches DBusMessages that have been freed so that they can be 
> reused later. There's a way to disable this caching by modifying a #define (I 
> don't know which one) in the library and recompiling.
> 
> > Is there a way to specify where to marshal to ?
> 
> No. It marshals to memory. Where else would it marshal to?

Wtf ? What if i want to marshal into a buffer that i made ?


> 
> Unless I didn't understand the question.
> 
> > Even worse, the unmarshal function will not tell me how much data was
> >  unmarshalled and so how do i parse packets with multiple messages in them
> >  ?
> 
> I think there's a function added in 1.2 that tells you how big a message is, 
> given a buffer. I don't know how it works.
> 
> If you don't want to use it, you can parse the header. There's a field in the 
> header that includes the size of the payload. But note that the size of the 
> header is also variable, so you need to find the end of the header too (there's 
> a variable-sized a(yv) array at the end, but its size is prepended to it).

Yeah.

> 
> > Here is the config file for the daemon. Perhaps max_replies_per_connection
> >  is being exceeded ? 
> 
> No.

ok, thanks.

> 
> >  Is that essentially maximum method calls per
> >  connection ? Does the dbus daemon drop the connection when these are
> >  exceeded ?
> 
> No. That's maximum simultaneous replies that a connection may have, before the 
> bus stops trying to track them. The reason the bus daemon tracks them at all 
> is to provide timeout replies.
> 
> -- 
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>   Senior Product Manager - Nokia, Qt Development Frameworks
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>