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

[Fabrizio L. <fa...@lu...>]

Okay, I ran dbus-monitor and all appears to be fine on the python end:

method call sender=:1.1093 -> dest=com.ssokolow.QuickTile serial=2
path=/com/ssokolow/QuickTile; interface=com.ssokolow.QuickTile;
member=doCommand
   string "right"
method return sender=:1.1091 -> dest=:1.1093 reply_serial=2
   boolean false

>From what I can see the message is sent by my application correctly, the
python code successfully does what its meant to do (despite it returning
false - I am not actually sure of the conditions of the return as I am not
really interested in it for my code) and the response is sent back with the
right destination (based on the fact that was the source of the request)
with the same serial.

I am no dbus expert but that output looks fine to me.

Whilst searching for a solution I did find the threads regarding the hang
on void return types; I am not sure if this is the same or similar problem?

Going to try and simplify my code just in-case my use of the return value
has caused some funky g++ compiler magic that results in the code breaking:
debugger is showing that bool _retval has been optimised out but that could
just be because it skips streaming retmsg >> _retval and just returns
_retval
​


Many Thanks,
Fabrizio Lungo

http://yours.sincere.ly/flungo/ <http://sincere.ly/flungo/>

On 22 December 2014 at 14:54, Robert Middleton <rmi...@sy...>
wrote:

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