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

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

The output from dbus-monitor does look correct.

It's also possible that g++ is be a little too helpful and optimizing some
of the values out.  I ran a quick test just now, and I was able to get a
bool value back.  Here's a .tgz of the code that I used to test:
http://rm5248.com/random/dbus-bool-test.tgz

On Mon, Dec 22, 2014 at 1:29 PM, Fabrizio Lungo <fa...@lu...> wrote:

> 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 Gitcdbs quilt
>>> libglibmm-2.4-dev doxygen xsltprocHub
>>> <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
>>>
>>>
>>
>>