Re: [Dbus-cxx-users] Hangs (deadlock) with return type of bool

[Robert M. <rmi...@sy...>]

There was a problem a long time ago with void methods not properly
returning; this could be a similar problem.

Could you run dbus-monitor at the same time and make sure that a
method_reply is being sent back from the python application?

On Mon, Dec 22, 2014 at 4:48 AM, Fabrizio Lungo <fa...@lu...> wrote:

> I am not sure if this is a bug with dbus-cxx or if I am doing something
> wrong. I am trying to use dbus-cxx to send a message to a dbus-python
> application (quicktile). Using d-feet I can see that the signature is doCommand
> (String command) |-> (Boolean arg_1). In cpp I have created a wrapper
> class for the method:
>
> *quickTileProxy.h
> <https://github.com/flungo/opensnap-quicktile/blob/feature/dbus/src/quickTileProxy.h>*
>
> #define QT_DBUS_NAME "com.ssokolow.QuickTile"#define QT_OBJECT_PATH "/com/ssokolow/QuickTile"#define QT_INTERFACE "com.ssokolow.QuickTile"
> class quickTileProxy {
>     DBus::ObjectProxy::pointer object;public:
>     DBus::MethodProxy<bool, std::string>& doCommand;
>     quickTileProxy(DBus::Connection::pointer connection);private:
>
> };
>
> *quickTileProxy.cpp
> <https://github.com/flungo/opensnap-quicktile/blob/feature/dbus/src/quickTileProxy.cpp>*
>
> #include <dbus-cxx.h>#include "quickTileProxy.h"
>
> quickTileProxy::quickTileProxy(DBus::Connection::pointer connection) :
>     object(connection->create_object_proxy(QT_DBUS_NAME, QT_OBJECT_PATH)),
>         doCommand(*(object->create_method<bool,std::string>(QT_INTERFACE,"doCommand")))
> {
>
> }
>
> This is instantiated with:
>
> *opensnap.cpp:181
> <https://github.com/flungo/opensnap-quicktile/blob/feature/dbus/src/opensnap.cpp#L181>*
>
> qt_proxy = new quickTileProxy(connection);
>
> and doCommand is called with the line:
>
> *opensnap.cpp:40
> <https://github.com/flungo/opensnap-quicktile/blob/feature/dbus/src/opensnap.cpp#L40>*
>
> rtn = qt_proxy->doCommand(args);
>
> The command runs successfully on the quicktile daemon and the action is
> performed however at this point the code hangs. Using gdb I have traced the
> point that the code hangs to between lines 127 and 128 of
> /usr/include/dbus-cxx-0.8/dbus-cxx/methodproxy.h:
>
> ReturnMessage::const_pointer retmsg = this->call( _callmsg );
> T_return _retval;
>
> The disassembly shows that it is in a __lll_lock_wait and would appear to
> be deadlocked. The full disassembly:
>
> __lll_lock_wait()
> __lll_lock_wait+28: mov    %edx,%eax
> __lll_lock_wait+30: xchg   %eax,(%rdi)
> __lll_lock_wait+32: test   %eax,%eax
> __lll_lock_wait+34: jne    0x7ffff2eb4115 <__lll_lock_wait+21>
> __lll_lock_wait+36: pop    %rdx
> __lll_lock_wait+37: pop    %r10
> __lll_lock_wait+39: retq
>
> I am currently using *aur/dbus-cxx 0.8.0-2* (which I think is the latest)
> from the Arch Linux AUR. If you would like to browse or download the full
> source code then it is available from GitHub
> <https://github.com/flungo/opensnap-quicktile/tree/feature/dbus>.
> Hopefully someone is able to shed some light on what is going wrong?
>
> I don’t *think* there is an issue with the python side of things as I can
> execute fine with d-feet but the source for this is also available on
> GitHub <https://github.com/ssokolow/quicktile>.
>
> Many Thanks,
> Fabrizio Lungo
>
> http://yours.sincere.ly/flungo/ <http://sincere.ly/flungo/>
> ​
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Dbus-cxx-users mailing list
> Dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cxx-users
>
>