All quiet on the dbus bus

[Simon Burton]

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.
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 ?
It seems that dbus_connection_send always writes immediately (in this app) so
dbus_connection_get_outgoing_size always reports 0.

It looks like dbus_message_marshal allocates some memory to store the marshal to.
How do I free this memory ?
Is there a way to specify where to marshal to ?
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 ?

Here is the config file for the daemon. Perhaps max_replies_per_connection is being exceeded ?
Is that essentially maximum method calls per connection ? Does the dbus daemon drop the connection
when these are exceeded ?


<busconfig>
  <!-- Our well-known bus type, don't change this -->
  <type>session</type>

  <!-- If we fork, keep the user's original umask to avoid affecting
       the behavior of child processes. -->
<!--
  <keep_umask/>
-->

  <listen>tcp:host=localhost,port=9001,bind=*</listen>

  <standard_session_servicedirs />

  <policy context="default">
    <!-- Allow everything to be sent -->
    <allow send_destination="*" eavesdrop="true"/>
    <!-- Allow everything to be received -->
    <allow eavesdrop="true"/>
    <!-- Allow anyone to own anything -->
    <allow own="*"/>
  </policy>

  <allow_anonymous />

  <!-- For the session bus, override the default relatively-low limits 
       with essentially infinite limits, since the bus is just running 
       as the user anyway, using up bus resources is not something we need 
       to worry about. In some cases, we do set the limits lower than 
       "all available memory" if exceeding the limit is almost certainly a bug, 
       having the bus enforce a limit is nicer than a huge memory leak. But the 
       intent is that these limits should never be hit. -->

  <!-- the memory limits are 1G instead of say 4G because they can't exceed 32-bit signed int max -->
  <limit name="max_incoming_bytes">1000000000</limit>
  <limit name="max_outgoing_bytes">1000000000</limit>
  <limit name="max_message_size">1000000000</limit>
  <limit name="service_start_timeout">120000</limit>  
  <limit name="auth_timeout">240000</limit>
  <limit name="max_completed_connections">100000</limit>  
  <limit name="max_incomplete_connections">10000</limit>
  <limit name="max_connections_per_user">100000</limit>
  <limit name="max_pending_service_starts">10000</limit>
  <limit name="max_names_per_connection">50000</limit>
  <limit name="max_match_rules_per_connection">50000</limit>
  <limit name="max_replies_per_connection">50000</limit>
  <limit name="reply_timeout">300000</limit>

</busconfig>