dbus-cxx-devel — For development of dbus-cxx itself

Re: [Dbus-cxx-devel] Uninitialized/destroyed mutexes/rwlocks

[Rick L. V. Jr. <rvi...@cs...>]

Thanks Patrick for the patches.

I'll try and get them incorporated later today or tomorrow and push out a
new release.

---

Rick


Patrick Allison wrote:
> On Fri, 2009-09-11 at 08:59 -1000, Patrick Allison wrote:
>> Think I found the last bug that was causing occasional deadlocks in my
>> code using dbus-cxx (turns out it wasn't just the unsent messages).
>
> Haha, that statement was just *asking* for trouble.
>
> There's danger in Dispatcher::watch_thread_main -
>
>       // Now we'll check the fds that are ready for writing and add them
> to the set of write fds to handle
>       pthread_mutex_lock( &m_mutex_write_watches );
>       for ( fditer = m_enabled_write_fds.begin(); fditer !=
> m_enabled_write_fds.end(); fditer++ )
>       {
>         if ( FD_ISSET( *fditer, &write_fds ) )
>         {
>           witer = m_write_watches.find(*fditer);
>           if ( witer != m_write_watches.end() )
>             witer->second->handle_write();
>         }
>       }
>       pthread_mutex_unlock( &m_mutex_write_watches );
>
> Here, m_mutex_write_watches is being held over a dbus call, which has a
> deadlock risk (thread A takes lock 1 (m_mutex_write_watches), thread A
> wakes thread B, thread B takes lock 2 (a mutex inside libdbus), thread B
> waits on lock 1, thread A waits on lock 2 - doooom), and there's not
> much reason for it. You can always do:
>
>       // Now we'll check the fds that are ready for writing and add them
> to the set of write fds to handle
>       for ( fditer = m_enabled_write_fds.begin(); fditer !=
> m_enabled_write_fds.end(); fditer++ )
>       {
>         if ( FD_ISSET( *fditer, &write_fds ) )
>         {
>           pthread_mutex_lock( &m_mutex_write_watches );
>           witer = m_write_watches.find(*fditer);
>           if ( witer != m_write_watches.end() ) {
>             Watch::pointer wp = witer->second;
>             pthread_mutex_unlock( &m_mutex_write_watches );
>             wp->handle_write();
>           } else {
>             pthread_mutex_unlock( &m_mutex_write_watches );
>           }
>         }
>       }
>
> and identically for the read watches.
>
> Patch attached.
>
> Patrick
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.
> http://p.sf.net/sfu/bobj-july_______________________________________________
> Dbus-cxx-devel mailing list
> Dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cxx-devel
>

Re: [Dbus-cxx-devel] problem: multithreaded dbus-cxx apps

[Rick L. V. Jr. <rvi...@cs...>]

Hello,

Oliver Kowalke wrote:
> Hi,
>
> I've several apps using DBus and acting as server as well as client.
> Common
> pattern: app A registers on DBus signal Sig1 of app B. signal handler
> (callback) of Sig1 does some work including invoking method x() of app C
> (via
> DBus -> dbus_send_with_reply_blocking() or so).
> The problem is that the apps must be multithreaded too (for
> responsiveness).
> I wrote a small test app (echo_server, echo_client) where the client calls
> echo_serve::request() in 5 threads at the same time. I get sometimes
> exceptions thrown ("Not enought memory"). It seams to me this error is
> raised
> inside dbus (not dbus-cxx).
> My question is: is dbus-cxx prepared to be used in a multithreaded env
> where
> the app actrs a cleint as well server?

The intent is that it will work as a client as well as a server.

Have you applied any of the patches that Patrick Allison recently posted?
They related to the multi-threaded code and it's likely you're running up
against the bugs he tracked down.

Hopefully I'll have a chance later today or tomorrow to take a fuller look
at the patches and push out an update.



>
> regards,
> Oliver
>
> #### echo ###
>
> #ifndef TEST_ECHO_H
> #define TEST_ECHO_H
>
> #include <string>
>
> #include <sigc++/sigc++.h>
>
> namespace test {
>
> class echo
> {
> private:
>     sigc::signal< void, std::string > sig_;
>
> public:
>     std::string reply( std::string msg)
>     { return msg; }
>
>     sigc::signal< void, std::string > signal_event()
>     { return sig_; }
>
>     void do_emit_event( std::string const& msg)
>     { sig_.emit( msg); }
> };
>
> }
>
> #endif // TEST_ECHO_H
>
>
>
> ### server ####
>
> #include "echo_adapter.h"
> #include "echo.h"
>
> int main()
> {
>   DBus::init();
>
>   int ret;
>
>   DBus::Dispatcher dispatcher;
>
>   DBus::Connection::pointer conn =
> dispatcher.create_connection(DBus::BUS_SYSTEM);
>
>   // request a name on the bus
>   ret = conn->request_name( "test.echo.server",
> DBUS_NAME_FLAG_REPLACE_EXISTING);
>   if (DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER != ret) return 1;
>
>   test::echo handler;
>
>   test::echoAdapter::pointer adapter =
> test::echoAdapter::create(&handler);
>
>   conn->register_object( adapter);
>
>   std::cout << "Running" << std::flush;
>
>   for(;;)
>   {
>     std::cout << "." << std::flush;
>     sleep(1);
>   }
>
>   std::cout << std::endl;
>
>   return 0;
>
> }
>
>
> #### client #####
>
> include <iostream>
> #include <stdexcept>
> #include <sstream>
> #include <string>
>
> #include <boost/bind.hpp>
> #include <boost/ref.hpp>
> #include <boost/thread.hpp>
>
> #include "echo_proxy.h"
>
> #include <cstdlib>
>
> void request(
>         boost::barrier & b,
>         test::echoProxy::pointer echo,
>         std::string const& msg)
> {
>     std::stringstream ss;
>     ss << boost::this_thread::get_id();
>
>     try
>     {
>         b.wait();
>         fprintf( stderr, "thread %s: request == %s, reply == %s\n",
> ss.str().c_str(),  msg.c_str(), echo->reply( msg).c_str() );
>     }
>     catch ( std::exception const& e)
>     {
>         fprintf( stderr, "thread %s: exception catched == %s\n",
> ss.str().c_str(), e.what() );
>         ::abort();
>     }
>     catch (...)
>     { fprintf( stderr, "thread %s: unhandled exception catched\n",
> ss.str().c_str() ); }
> }
>
> int main(int argc, const char** argv)
> {
>     try
>     {
>         DBus::init();
>         DBus::Dispatcher dispatcher;
>         DBus::Connection::pointer connection =
> dispatcher.create_connection(
> DBus::BUS_SYSTEM);
>         test::echoProxy::pointer echo = test::echoProxy::create(
> connection);
>
>         boost::thread_group tg;
>         boost::barrier b( 5);
>
>         tg.create_thread(
>                 boost::bind(
>                     & request,
>                     boost::ref( b),
>                     echo,
>                     "abc") );
>         tg.create_thread(
>                 boost::bind(
>                     & request,
>                     boost::ref( b),
>                     echo,
> 		    "def") );
>         tg.create_thread(
>                 boost::bind(
>                     & request,
>                     boost::ref( b),
>                     echo,
>                     "ghi") );
>         tg.create_thread(
>                 boost::bind(
>                     & request,
>                     boost::ref( b),
>                     echo,
>                     "jkl") );
>         tg.create_thread(
>                 boost::bind(
>                     & request,
>                     boost::ref( b),
>                     echo,
>                     "mno") );
>
>         tg.join_all();
>
>         return 0;
>     }
>     catch ( std::exception const& e)
>     { std::cerr << "exception catched: " << e.what() << std::endl; }
>     catch (...)
>     { std::cerr << "unhandled exception catched" << std::endl; }
>
>     return -1;
> }
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register
> now&#33;
> http://p.sf.net/sfu/devconf_______________________________________________
> Dbus-cxx-devel mailing list
> Dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cxx-devel
>

[Dbus-cxx-devel] problem: multithreaded dbus-cxx apps

[Oliver K. <oli...@se...>]

Hi,

I've several apps using DBus and acting as server as well as client. Common 
pattern: app A registers on DBus signal Sig1 of app B. signal handler 
(callback) of Sig1 does some work including invoking method x() of app C (via 
DBus -> dbus_send_with_reply_blocking() or so).
The problem is that the apps must be multithreaded too (for responsiveness).
I wrote a small test app (echo_server, echo_client) where the client calls 
echo_serve::request() in 5 threads at the same time. I get sometimes 
exceptions thrown ("Not enought memory"). It seams to me this error is raised 
inside dbus (not dbus-cxx).
My question is: is dbus-cxx prepared to be used in a multithreaded env where 
the app actrs a cleint as well server?

regards,
Oliver

#### echo ###

#ifndef TEST_ECHO_H
#define TEST_ECHO_H

#include <string>

#include <sigc++/sigc++.h>

namespace test {

class echo
{
private:
    sigc::signal< void, std::string > sig_;

public:
    std::string reply( std::string msg)
    { return msg; }

    sigc::signal< void, std::string > signal_event()
    { return sig_; }

    void do_emit_event( std::string const& msg)
    { sig_.emit( msg); }
};

}

#endif // TEST_ECHO_H



### server ####

#include "echo_adapter.h"
#include "echo.h"

int main()
{
  DBus::init();

  int ret;

  DBus::Dispatcher dispatcher;

  DBus::Connection::pointer conn = 
dispatcher.create_connection(DBus::BUS_SYSTEM);

  // request a name on the bus
  ret = conn->request_name( "test.echo.server", 
DBUS_NAME_FLAG_REPLACE_EXISTING);
  if (DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER != ret) return 1;

  test::echo handler;

  test::echoAdapter::pointer adapter = test::echoAdapter::create(&handler);

  conn->register_object( adapter);

  std::cout << "Running" << std::flush;

  for(;;)
  {
    std::cout << "." << std::flush;
    sleep(1);
  }

  std::cout << std::endl;

  return 0;

}


#### client #####

include <iostream>
#include <stdexcept>
#include <sstream>
#include <string>

#include <boost/bind.hpp>
#include <boost/ref.hpp>
#include <boost/thread.hpp>

#include "echo_proxy.h"

#include <cstdlib>

void request(
        boost::barrier & b,
        test::echoProxy::pointer echo,
        std::string const& msg)
{
    std::stringstream ss;
    ss << boost::this_thread::get_id();

    try
    {
        b.wait();
        fprintf( stderr, "thread %s: request == %s, reply == %s\n", 
ss.str().c_str(),  msg.c_str(), echo->reply( msg).c_str() );
    }
    catch ( std::exception const& e)
    {
        fprintf( stderr, "thread %s: exception catched == %s\n", 
ss.str().c_str(), e.what() );
        ::abort();
    }
    catch (...)
    { fprintf( stderr, "thread %s: unhandled exception catched\n", 
ss.str().c_str() ); }
}

int main(int argc, const char** argv)
{
    try
    {
        DBus::init();
        DBus::Dispatcher dispatcher;
        DBus::Connection::pointer connection = dispatcher.create_connection( 
DBus::BUS_SYSTEM);
        test::echoProxy::pointer echo = test::echoProxy::create( connection);

        boost::thread_group tg;
        boost::barrier b( 5);

        tg.create_thread(
                boost::bind(
                    & request,
                    boost::ref( b),
                    echo,
                    "abc") );
        tg.create_thread(
                boost::bind(
                    & request,
                    boost::ref( b),
                    echo,
		    "def") );
        tg.create_thread(
                boost::bind(
                    & request,
                    boost::ref( b),
                    echo,
                    "ghi") );
        tg.create_thread(
                boost::bind(
                    & request,
                    boost::ref( b),
                    echo,
                    "jkl") );
        tg.create_thread(
                boost::bind(
                    & request,
                    boost::ref( b),
                    echo,
                    "mno") );

        tg.join_all();

        return 0;
    }
    catch ( std::exception const& e)
    { std::cerr << "exception catched: " << e.what() << std::endl; }
    catch (...)
    { std::cerr << "unhandled exception catched" << std::endl; }

    return -1;
}

Re: [Dbus-cxx-devel] Uninitialized/destroyed mutexes/rwlocks

[Patrick A. <pa...@ph...>]

On Fri, 2009-09-11 at 08:59 -1000, Patrick Allison wrote:
> Think I found the last bug that was causing occasional deadlocks in my
> code using dbus-cxx (turns out it wasn't just the unsent messages).

Haha, that statement was just *asking* for trouble.

There's danger in Dispatcher::watch_thread_main -

      // Now we'll check the fds that are ready for writing and add them
to the set of write fds to handle
      pthread_mutex_lock( &m_mutex_write_watches );
      for ( fditer = m_enabled_write_fds.begin(); fditer !=
m_enabled_write_fds.end(); fditer++ )
      {
        if ( FD_ISSET( *fditer, &write_fds ) )
        {
          witer = m_write_watches.find(*fditer);
          if ( witer != m_write_watches.end() )
            witer->second->handle_write();
        }
      }
      pthread_mutex_unlock( &m_mutex_write_watches );

Here, m_mutex_write_watches is being held over a dbus call, which has a
deadlock risk (thread A takes lock 1 (m_mutex_write_watches), thread A
wakes thread B, thread B takes lock 2 (a mutex inside libdbus), thread B
waits on lock 1, thread A waits on lock 2 - doooom), and there's not
much reason for it. You can always do:

      // Now we'll check the fds that are ready for writing and add them
to the set of write fds to handle
      for ( fditer = m_enabled_write_fds.begin(); fditer !=
m_enabled_write_fds.end(); fditer++ )
      {
        if ( FD_ISSET( *fditer, &write_fds ) )
        {
          pthread_mutex_lock( &m_mutex_write_watches );
          witer = m_write_watches.find(*fditer);          
          if ( witer != m_write_watches.end() ) {
            Watch::pointer wp = witer->second;
            pthread_mutex_unlock( &m_mutex_write_watches );
            wp->handle_write();
          } else {
            pthread_mutex_unlock( &m_mutex_write_watches );
          }
        }
      }

and identically for the read watches. 

Patch attached.

Patrick

[Dbus-cxx-devel] Uninitialized/destroyed mutexes/rwlocks

[Patrick A. <pa...@ph...>]

Think I found the last bug that was causing occasional deadlocks in my
code using dbus-cxx (turns out it wasn't just the unsent messages).

Several of the pthread_cond/rwlock/mutexes used in dbus-cxx are never
initialized (using pthread_*_init), in the object's constructor, and
none of them are destroyed (using pthread_*_destroy). The uninitialized
ones (in object.cpp and objectproxy.cpp) were causing the deadlocks when
they got set up from non-zeroed memory, but the missing
pthread_*_destroy isn't a good thing either.

Patch attached which fixes all of that.

Patrick

Re: [Dbus-cxx-devel] Some 'sent' messages don't get sent

[Patrick A. <pa...@ph...>]

Rick:

I also added a bug to the dbus bugzilla:

https://bugs.freedesktop.org/show_bug.cgi?id=23584

with a bit more information, including a logfile showing the problem 
happening. It also may be possible to create a testcase that forces this 
problem to occur by adding a mutex or something inside on_wakeup_main that 
prevents that function from exiting until the dispatch loop executes 
once.

I'll check your fix as soon as I can to see if it works.

Patrick

On Tue, 1 Sep 2009, Rick L. Vinyard, Jr. wrote:

> Patrick Allison wrote:
>
>> A (bad) workaround in dbus-cxx would be a mutex preventing messages from
>> being dispatched while in the read handler in the watch thread.
>>
>
> I've forwarded your emails to the dbus development list to hopefully start
> a discussion as to whether there is a bug in dbus or dbus-cxx' use of
> dbus.
>
> In the meantime I've commited what I hope will fix the problem. It's
> difficult for me to test since my systems don't seem to experience the
> same bug.
>
> In short, the fix (hopefully only temporary until we figure out which
> library the bug is in) simply initiates processing in the dispatch thread
> if any read or write watch activity occurred.
>
> That should allow the dispatch thread and watch thread to operate at full
> capacity without any dependent locking and still make sure that any
> silently queued messages are still dealt with.
>
> The fixed version is currently in subversion:
> http://sourceforge.net/projects/dbus-cxx/develop
>
> Let me know if this fixes the problem and I'll push out a general release.
>
> Thanks Patrick for tracking this one down,
>
> ----
>
> Rick
>
>

Re: [Dbus-cxx-devel] Some 'sent' messages don't get sent

[Rick L. V. Jr. <rvi...@cs...>]

Patrick Allison wrote:

> A (bad) workaround in dbus-cxx would be a mutex preventing messages from
> being dispatched while in the read handler in the watch thread.
>

I've forwarded your emails to the dbus development list to hopefully start
a discussion as to whether there is a bug in dbus or dbus-cxx' use of
dbus.

In the meantime I've commited what I hope will fix the problem. It's
difficult for me to test since my systems don't seem to experience the
same bug.

In short, the fix (hopefully only temporary until we figure out which
library the bug is in) simply initiates processing in the dispatch thread
if any read or write watch activity occurred.

That should allow the dispatch thread and watch thread to operate at full
capacity without any dependent locking and still make sure that any
silently queued messages are still dealt with.

The fixed version is currently in subversion:
http://sourceforge.net/projects/dbus-cxx/develop

Let me know if this fixes the problem and I'll push out a general release.

Thanks Patrick for tracking this one down,

----

Rick

Re: [Dbus-cxx-devel] Some 'sent' messages don't get sent

[Rick L V. Jr <rvi...@cs...>]

Two definitely aren't a flurry.

I should have some time to look further into it early next week, but it
looks like you've mostly tracked it down.

If dbus-cxx needs temporary patches to get around bugs that sounds fine
to me.

---

Rick


Patrick Allison wrote:
> Hi again:
> 
> Sorry for the flurry of messages (OK, two is not a flurry), but I did a 
> bit more debugging staring around at code. I think the problem's a race 
> condition between the watch thread and the dispatch thread (and I really 
> hope this isn't just some bug in my version of D-Bus, but I didn't see 
> anything like it in the bugzilla for D-Bus).
> 
>>From what I can see, the problem is that:
> 1) a request comes in, which wakes the watch thread, and calls 
> dbus_handle_watch.
> 
> 2) This calls "_dbus_connection_acquire_io_path" in 
> _dbus_connection_handle_watch, which locks the I/O path.
> 
> 3) While the I/O path is held, _dbus_connection_handle_watch calls 
> _dbus_transport_handle_watch, which reads the message, and calls 
> _dbus_connection_queue_received_message_link.
> 
> 4) _dbus_connection_queue_received_message_link calls
> _dbus_connection_wakeup_mainloop, which wakes the dispatch thread. NOTE: 
> I have no idea why _dbus_connection_queue_received_message_link does this. 
> I don't believe it should - it has no reason to wake up the main loop. The 
> watch handler, when it's done, should wake the main loop by changing the 
> dispatch status.
> 
> 5) The dispatch thread wakes up, grabs the data, dispatches it, calls the 
> function. That function returns a value, which causes Connection::send to 
> be called, which calls dbus_connection_send.
> 
> 6) dbus_connection_send calls _dbus_connection_acquire_io_path, which 
> fails (since it's still being held in the watch thread!) and the message 
> quietly gets queued without anyone knowing that it needs to be.
> 
> To me, this looks like a bug in D-Bus: if _dbus_connection_acquire_io_path 
> fails during a write, it should enable the write watch if it's disabled: 
> this might seem silly, as select() will immediately say "writeable", but 
> the write watch shouldn't care *why* a write got queued, only that it did 
> and it needs to be handled when the application gets a chance.
> 
> A (bad) workaround in dbus-cxx would be a mutex preventing messages from 
> being dispatched while in the read handler in the watch thread.
> 
> Patrick
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Dbus-cxx-devel mailing list
> Dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cxx-devel

Re: [Dbus-cxx-devel] Some 'sent' messages don't get sent

[Patrick A. <pa...@ph...>]

Hi again:

Sorry for the flurry of messages (OK, two is not a flurry), but I did a 
bit more debugging staring around at code. I think the problem's a race 
condition between the watch thread and the dispatch thread (and I really 
hope this isn't just some bug in my version of D-Bus, but I didn't see 
anything like it in the bugzilla for D-Bus).

>From what I can see, the problem is that:
1) a request comes in, which wakes the watch thread, and calls 
dbus_handle_watch.

2) This calls "_dbus_connection_acquire_io_path" in 
_dbus_connection_handle_watch, which locks the I/O path.

3) While the I/O path is held, _dbus_connection_handle_watch calls 
_dbus_transport_handle_watch, which reads the message, and calls 
_dbus_connection_queue_received_message_link.

4) _dbus_connection_queue_received_message_link calls
_dbus_connection_wakeup_mainloop, which wakes the dispatch thread. NOTE: 
I have no idea why _dbus_connection_queue_received_message_link does this. 
I don't believe it should - it has no reason to wake up the main loop. The 
watch handler, when it's done, should wake the main loop by changing the 
dispatch status.

5) The dispatch thread wakes up, grabs the data, dispatches it, calls the 
function. That function returns a value, which causes Connection::send to 
be called, which calls dbus_connection_send.

6) dbus_connection_send calls _dbus_connection_acquire_io_path, which 
fails (since it's still being held in the watch thread!) and the message 
quietly gets queued without anyone knowing that it needs to be.

To me, this looks like a bug in D-Bus: if _dbus_connection_acquire_io_path 
fails during a write, it should enable the write watch if it's disabled: 
this might seem silly, as select() will immediately say "writeable", but 
the write watch shouldn't care *why* a write got queued, only that it did 
and it needs to be handled when the application gets a chance.

A (bad) workaround in dbus-cxx would be a mutex preventing messages from 
being dispatched while in the read handler in the watch thread.

Patrick

[Dbus-cxx-devel] Some 'sent' messages don't get sent

[Patrick A. <pa...@ph...>]

Hi all:

I'm having a bit of a problem with messages occasionally getting 'stuck' 
and being unsent somehow. I've turned on libdbus debugging and dbus-cxx 
debugging, and I think I see why it's happening, but I can't see where the 
bug is.

One bug I *did* find that I really, really thought would fix it, but 
didn't, was that Connection::on_remove_watch_callback was signalling 
"signal_add_watch" rather than "signal_remove_watch", and similarly 
Connection::on_watch_toggled_callback was signaling "signal_add_watch" 
instead of "signal_watch_toggled" (connection.cpp, lines 845 and 851)

I see this problem when one process calls a method in another process, and 
the reply message gets "lost" - it never shows up in a D-Bus monitor, and 
I'm pretty sure it's never getting sent:

A "correct" reply looks like this. I put a debug statement in 
Connection::send to see when 'send' is called, so that's what starts this 
debugging output.

3081477008: Connection::send
16976:   LOCK: dbus_connection_send
16976: Message 0x88d7df8 (2 no path no interface no member 'i') for :1.36 added to outgoing queue 0x88d79d0, 1 pending to send
16976: Message 0x88d7df8 serial is 5
16976: _dbus_connection_do_iteration_unlocked start
16976:   UNLOCK: _dbus_connection_acquire_io_path
16976: _dbus_connection_acquire_io_path locking io_path_mutex
16976: _dbus_connection_acquire_io_path start connection->io_path_acquired = 0 timeout = 0
16976: _dbus_connection_acquire_io_path end connection->io_path_acquired = 1 we_acquired = 1
16976: _dbus_connection_acquire_io_path unlocking io_path_mutex
16976:   LOCK: _dbus_connection_acquire_io_path
16976: Transport iteration flags 0x1 timeout -1 connected = 1
16976:  iteration flags = write timeout = -1 read_watch = 0x88d7680 write_watch = 0x88d7658 fd = 3
16976: do_writing(), have_messages = 1, fd = 3
16976:  wrote 52 bytes of 52
16976: Message 0x88d7df8 (2 no path no interface no member 'i') removed from outgoing queue 0x88d79d0, 0 left to send
16976: check_write_watch(): needed = 0 on connection 0x88d79d0 watch 0x88d7658 fd = 3 outgoing messages exist 0
16976:   UNLOCK: protected_change_watch
16976:   LOCK: protected_change_watch
16976:  ... leaving do_iteration()
16976: _dbus_transport_do_iteration end
16976: _dbus_connection_release_io_path locking io_path_mutex
16976: _dbus_connection_release_io_path start connection->io_path_acquired = 1
16976: _dbus_connection_release_io_path unlocking io_path_mutex
16976: _dbus_connection_do_iteration_unlocked end
16976: _dbus_connection_send_preallocated_and_unlock middle
16976: dispatch status = complete is_connected = 1
16976:   UNLOCK: _dbus_connection_update_dispatch_status_and_unlock
3081477008: Object::handle_message: message was handled

And here's one from later in that session, when the message was "lost" and 
the reply timed out:

3081477008: Connection::send
16976:   LOCK: dbus_connection_send
16976: Message 0x88d9bf0 (2 no path no interface no member 's') for :1.37 added to outgoing queue 0x88d79d0, 1 pending to send
16976: Message 0x88d9bf0 serial is 8
16976: _dbus_connection_do_iteration_unlocked start
16976:   UNLOCK: _dbus_connection_acquire_io_path
16976: _dbus_connection_acquire_io_path locking io_path_mutex
16976: _dbus_connection_acquire_io_path start connection->io_path_acquired = 1 timeout = 0
16976: _dbus_connection_acquire_io_path waiting 0 for IO path to be acquirable
16976: _dbus_connection_acquire_io_path end connection->io_path_acquired = 1 we_acquired = 0
16976: _dbus_connection_acquire_io_path unlocking io_path_mutex
16976:   LOCK: _dbus_connection_acquire_io_path
16976: _dbus_connection_do_iteration_unlocked end
3081477008: Dispatcher::on_wakeup_main
16976: _dbus_connection_send_preallocated_and_unlock middle
16976: dispatch status = complete is_connected = 1
16976:   UNLOCK: _dbus_connection_update_dispatch_status_and_unlock
3081477008: Object::handle_message: message was handled

>From what I've been able to figure out, whenever dbus_connection_send 
can't write to the socket immediately, it's supposed to queue the message, 
and if the queue went from 0->1 it's supposed to toggle the write watch to 
tell the main thread to select()/poll() on the write fd.

As far as I can tell, that's not happening for some reason. I never see 
on_watch_toggled_callback called, and the write watch is never enabled 
(it's added to the watch list unenabled).

The next time that Connection::send is called, it had 2 pending to send, 
then 3 pending to send, etc., so clearly the write watch isn't being 
handled. At that point the programs which are connecting to it usually die 
due to a timeout expiring, so it's not a temporary thing.

I worked around the problem by having Connection::send call 
Connection::flush, but that's not exactly the ideal solution. Works for 
now, though...

I'm attaching the full debug log - it's pretty verbose, and there's a lot 
going on (there's output from the main program as well, and also a few 
additional debugging outputs I added).

(Note that this is libdbus 1.2.16., and dbus-cxx 0.4.1)

Patrick

[Dbus-cxx-devel] [dbus-cxx - Developers] dbus-cxx 0.4.2 released

[SourceForge.net <no...@so...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=7580653
By: rvinyard

There are no code changes in this release.

This release adds support for building debian packages. You can use 'make deb'
to
build the debian packages. The debian build files are in the typical debian/
directory.

As this is my first attempt at a debian cdbs package there are bound to
be issues,
but it was tested on Ubuntu-Jaunty-i386 and all seemed well enough.

Also, this release splits the docs into their own download file. This should
make
it a bit easier for those without broadband.


______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=943816

[Dbus-cxx-devel] [dbus-cxx - Developers] RE: Is ABI/API stable?

[SourceForge.net <no...@so...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=7530209
By: weboide

I now understand the reasons, thank you for being very clear!
Maybe an integration directly into my project would be better at this point.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=943816

[Dbus-cxx-devel] [dbus-cxx - Developers] RE: Is ABI/API stable?

[SourceForge.net <no...@so...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=7530152
By: rvinyard

It's nowhere near API/ABI stable yet. There are still some pretty significant
changes that need to occur, including support of structures and arrays.

With the exception of a handful of bug-fix releases dbus-cxx is still new enough
that almost every release is breaking API/ABI compatibility in some way.

I've tried to increment the minor number when I'm certain something that breaks
either API or ABI compatibility is introduced, and increment only the micro
release for the bug fixes.

I put the libtool soname versioning stuff into the automake files so that when
some semblance of stability is reached it can be turned on. Otherwise, it would
simply be incrementing with each release with 'age' always remaining at 0.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=943816

[Dbus-cxx-devel] [dbus-cxx - Developers] Is ABI/API stable?

[SourceForge.net <no...@so...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=7529971
By: weboide

Hello,
I need to package dbus-cxx for Ubuntu (as a non-official package) so that I
can use it with my future project without much hassle.
The problem is that the SONAME doesn't seem to be bumped when API changes.
In configure.in,  I see that LIBTOOL_SO_VERSION=0:0:0 but the API changed a
couple times.

It would helpful to be able to rely on the SONAME, and would also help linux
distributions integrate this library into their repositories.

Thank you,
Arnaud.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=943816

[Dbus-cxx-devel] [dbus-cxx - Developers] Split Documentation

[SourceForge.net <no...@so...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=7514643
By: jeremyh_net

I would suggest that you split the documentation into it's own file to keep
the source-code download small. Your library is really great, but a 25MB download
might discourage some people from trying it out (especially people without
broadband).

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=943816

[Dbus-cxx-devel] [dbus-cxx - Developers] dbus-cxx 0.4.1 released

[SourceForge.net <no...@so...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=7482747
By: rvinyard

This release adds support to dbus-cxx-xml2cpp allowing proxies to multiply inherit
virtual interfaces. An example demonstrating how to use this feature can be
found in examples/xml2cpp/calculator-interface.

Additionally, a few warnings were cleaned up including one regarding unused
values when debugging output is turned off.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=943816

[Dbus-cxx-devel] [dbus-cxx - Developers] dbus-cxx 0.4.0 released

[SourceForge.net <no...@so...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=7451764
By: rvinyard

This release introduces the dbus-cxx-glibmm library to provide a means of integrating
dbus-cxx with glibmm. The key class is DBus::Glib::Dispatcher which performs
exactly like DBus::Dispatcher except all actual dispatching occurs in the Glibmm
main loop.

Since Gtkmm uses Glibmm for it's main loop this also provides a mechanism for
integrating dbus-cxx into Gtkmm.

To enable glibmm support pass --enable-glibmm to configure.

There are also a few new changes to DBus::Dispatcher. The constructor now accepts
a boolean parameter is_running (defaults to true) that will automatically start
the dispatcher when constructed. Also, the dispatcher will call stop() on destruction
to effect an orderly shutdown.

DBus::Dispatcher has had a few bugs fixed and a few missing pieces filled in. 

The watch thread finally has support for the case where there are no watches.
Instead, the watch thread will use sleep for the same timeout period as select()
was using and upon reawakening will check for new watches.

A missing mutex was also added to DBus::Dispatcher::create_connection(), and
a hack was removed from the dispatch thread that called flush() on each connection
(the auto-start on the Dispatchers revealed the source of the problem and the
need for the hack).

Finally, the standard pointer typedef and static create() methods were added
to the dispatcher classes to standardize across all dbus-cxx classes.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=943816

[Dbus-cxx-devel] [dbus-cxx - Developers] dbus-cxx 0.3.4 released

[SourceForge.net <no...@so...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=7449645
By: rvinyard

This is primarily a bugfix release. The introspection method in signal_base
now returns a null string. In the proxy/adapter generator dbus-cxx-xml2cpp the
castable types now are individually guarded in #defines to alleviate the case
where more than one proxy or adapter defines the same message iterator
overloads.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=943816

[Dbus-cxx-devel] [dbus-cxx - Developers] dbus-cxx 0.3.3 released

[SourceForge.net <no...@so...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=7447735
By: rvinyard

This release introduces a new macro DBUS_CXX_ITERATOR_SUPPORT to support types
that are not natively supported by dbus-cxx but can be static_cast<> to a supported
type. This is typically most useful for supporting enumeration types.

dbus-cxx-xml2cpp has been modified to use DBUS_CXX_ITERATOR_SUPPORT to support
castable types when generating proxy and adapter interfaces for both methods
and signals.

The example computer-is-a has been modified to demonstrate the use
of dbus-cxx-xml2cpp and enums with both methods and signals.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=943816

[Dbus-cxx-devel] [dbus-cxx - Developers] dbus-cxx 0.3.2 released

[SourceForge.net <no...@so...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=7445953
By: rvinyard

This release adds support to dbus-cxx-xml2cpp which generates C++ proxies and
adapters from DBus XML introspection-like files.

The 'cpptype' attribute to 'arg' nodes now allows specific types to be associated
with an argument when the proxy and adapter are generated. This is particularly
useful for generating methods that have enumeration types.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=943816

[Dbus-cxx-devel] [dbus-cxx - Developers] dbus-cxx 0.3.1 released

[SourceForge.net <no...@so...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=7441107
By: rvinyard

This is a bugfix release that corrects an issue with the Dispatcher that caused
100% cpu utilization. Thanks to Patrick Allison for hunting this one down.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=943816

[Dbus-cxx-devel] [dbus-cxx - Developers] dbus-cxx 0.3.0 released

[SourceForge.net <no...@so...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=7433043
By: rvinyard

This release adds support for char, int8_t and float types as well as long int
and unsigned long int on 32-bit architectures. There is also a new example
demonstrating how to extend Message::iterator and Message::append_iterator with
operators << and >> to support new types.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=943816

[Dbus-cxx-devel] [dbus-cxx - Developers] dbus-cxx 0.2.0 released

[SourceForge.net <no...@so...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=7427534
By: rvinyard

This release introduces several new changes to both the main library as well
as the dbus-cxx-xml2cpp proxy/adapter generator.

The changes to the main library include a new class DBus::Path to encapsulate
and validate dbus paths. Also new in the main library is support for introspection,
including the DBus introspection interface now supported by DBus::Object. Also
new is support for child nodes in DBus::Object.

Changes to dbus-cxx-xml2cpp include support for both inheritance and containment
with examples of both in the has-a and is-a xml2cpp examples.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=943816

[Dbus-cxx-devel] [dbus-cxx - Developers] dbus-cxx 0.1.2 released

[SourceForge.net <no...@so...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=7415336
By: rvinyard

This release fixes a few minor bugs. The generator now uses the ::DBus:: namespace
rather than DBus:: to allow the use of the namespace DBus in other nested hierarchies
without ambiguity. The m4 generated files have also been cleaned up to eliminate
several no-op compiler warnings. The documentation has been updated to reflect
the fact that dbus-cxx is now available in Fedora directly and also includes
a short synopsis on dbus-cxx-xml2cpp. Finally, an autoconf macro has been added
(ax_dbus_cxx_xml2cpp.m4) to streamline using dbus-cxx-xml2cpp in downstream
projects.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=943816

[Dbus-cxx-devel] [dbus-cxx - Developers] dbus-cxx 0.1.1 released

[SourceForge.net <no...@so...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=7392274
By: rvinyard

This release cleans up a bit of the build system (the first release had trouble
on Ubuntu i386) and fixes a bug on Fedora 12 (rawhide) related to a change in
the C library strstr().

The rpm package also now contains a separate doc subpackage.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=943816