All quiet on the dbus bus

[Thiago Macieira]

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?

> 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?

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?

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).

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

No.

>  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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20100111/4c7cb825/attachment.pgp