If user try to remove the last reference of proxy, object, connection
or eldbus(lib) inside of message callback it was causing the
eldbus_pending_dispatch() being called 2 times, one because of the
eldbus_cancel() that is triggered when the last reference of the
message parent is removed and another after the return of the user
callback.
==6545== Invalid read of size 8
==6545== at 0x52F784E: eldbus_cbs_free_dispatch (eldbus_core.c:266)
==6545== by 0x53064AA: eldbus_pending_dispatch (eldbus_pending.c:227)
==6545== by 0x5305961: cb_pending (eldbus_pending.c:74)
==6545== by 0x6B29DB1: ??? (in /usr/lib/libdbus-1.so.3.8.9)
==6545== by 0x6B2D280: dbus_connection_dispatch (in /usr/lib/libdbus-1.so.3.8.9)
==6545== by 0x52F93B4: eldbus_idler (eldbus_core.c:773)
==6545== by 0x4E4B300: _ecore_call_task_cb (ecore_private.h:305)
==6545== by 0x4E4B78F: _ecore_idler_all_call (ecore_idler.c:143)
==6545== by 0x4E4EA73: _ecore_main_loop_spin_core (ecore_main.c:1768)
==6545== by 0x4E4EAF1: _ecore_main_loop_spin_timers (ecore_main.c:1802)
==6545== by 0x4E4ED01: _ecore_main_loop_iterate_internal (ecore_main.c:1925)
==6545== by 0x4E4D03B: ecore_main_loop_begin (ecore_main.c:983)
==6545== Address 0x701aa78 is 104 bytes inside a block of size 128 free'd
==6545== at 0x4C2B200: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6545== by 0x530655B: eldbus_pending_dispatch (eldbus_pending.c:241)
==6545== by 0x5306763: eldbus_pending_cancel (eldbus_pending.c:259)
==6545== by 0x52F29DB: _eldbus_proxy_clear (eldbus_proxy.c:146)
==6545== by 0x52F3057: _eldbus_proxy_unref (eldbus_proxy.c:244)
==6545== by 0x52F3393: eldbus_proxy_unref (eldbus_proxy.c:264)
==6545== by 0x401039: on_get_playlists (banshee.c:53)
==6545== by 0x5306493: eldbus_pending_dispatch (eldbus_pending.c:225)
==6545== by 0x5305961: cb_pending (eldbus_pending.c:74)
==6545== by 0x6B29DB1: ??? (in /usr/lib/libdbus-1.so.3.8.9)
==6545== by 0x6B2D280: dbus_connection_dispatch (in /usr/lib/libdbus-1.so.3.8.9)
==6545== by 0x52F93B4: eldbus_idler (eldbus_core.c:773)
Now we will remove the pending from parent pending list before
call the user callback, this way only the pending messages will
be canceled.
Also we need increase the eldbus reference before call
dbus_connection_dispatch() or user could remove the last reference of
eldbus inside of a message callback when we still are
holding one reference of the connection.
@fix
ref T1908
Summary: Fix Coverity CID1256952: reports a null derefence here due to
eldbus_message_new returning NULL, thus causing a null dereference
when trying to set reply->dbus_msg
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Some problems with the actual implementation:
- the reply should not be writable, as it can only be read.
- if an error happen dbus_connection_send_with_reply_and_block()
will return NULL so we need check before use it
- all other send calls remove one reference of the message
Now also it is creating a error message, so the caller can know why it fail.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: This adds the actual code to send a dbus message and block
while waiting for a reply.
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: This function will send a message to dbus and block while
waiting for a reply
NB: This is needed for our 'port to libinput', and for our 'opening up the
drm card without systemd' efforts
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: This adds a public facing API function to make dbus calls
which will block and wait for a reply. This is needed for a couple of
use cases in our Wayland efforts (libinput, etc).
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: This just adds the function prototype into the eldbus private
header. It will be used in the new proxy function
"eldbus_proxy_send_and_block"
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
This fixes the breakage when Eldbus_Service_Interface_Desc added a
wrongfully methods2 field to a class that is allocated by the user.
This patch adds the respective eldbus_service_interface_register2 and
eldbus_service_interface_fallback_register2 for registration of
Eldbus_Service_Interface_Desc2 which is now versioned. So future the
functions can be backwards compatible and the struct be forward
compatible and leaves the Eldbus_Service_Interface_Desc and
eldbus_service_interface_register and
eldbus_service_interface_fallback_register intact as it was in EFL
1.10.
This fixes T1408
Reviewers: cedric, stefan_schmidt, raster
Reviewed By: raster
Subscribers: cedric
Maniphest Tasks: T1408
Differential Revision: https://phab.enlightenment.org/D1188
Summary:
Removed the void* data variable from Eldbus_Method and created another
struct that has the void* data and added an array of Eldbus_Method2 in
the descriptor for the Eldbus_Service_Interface_Desc and making the
appropriate modifications in the implementation to use both
descriptions.
Reviewers: cedric, stefan_schmidt, raster
CC: cedric
Maniphest Tasks: T1408
Differential Revision: https://phab.enlightenment.org/D1139
Summary:
Applications can:
void method_callback(void* data, const Eldbus_Service_Interface* iface,
const Eldbus_Message* message);
struct { ... } data_struct;
Eldbus_Method methods[] =
{
"method1", ELDBUS_ARGS("b", "bool"), ELDBUS_ARGS("b", "bool"), ELDBUS_METHOD_FLAG_HAS_DATA
, (Eldbus_Method_Cb)&method_callback, &data_struct
};
And method_callback will be called with data parameter pointing to data_struct global object.
Also, Eldbus-cxx supports registering an interface passing a lambda or
function object as method. For example:
edb::service_interface iface = edb::service_interface_register
(c, path, interface
, es::method("SendStringAndBool"
, [expected_string, expected_bool] (std::string const& n, bool b
, bool* out)
{
std::cout << "Running SendStringAndBool" << std::endl;
ck_assert(n == expected_string);
ck_assert(b == expected_bool);
*out = b;
return n;
}
, es::ins<std::string, bool>("string", "bool")
, es::outs<std::string, bool>("string", "bool")
)
);
When a request for "SendStringAndBool" with the proper signature is
called, executes the lambda and replies with the return value and
its bool* out parameter value.
Reviewers: cedric, woohyun, raster
CC: savio, cedric
Differential Revision: https://phab.enlightenment.org/D1052
Being annoyed by different types of eina critical macros - CRI, CRIT,
CRITICAL -, I concluded to unify them to one. Discussed on IRC and
finally, CRI was chosen to meet the consistency with other macros -
ERR, WRN, INF, DBG - in terms of the number of characters.
If there is any missing bits, please let me know.
Summary:
Hello guys,
We are now working on a accessibility support for elementary (ATSPI2) and we need following function to correctly register application.
Reviewers: cedric, raster, lucasdemarchi
Reviewed By: raster
Differential Revision: https://phab.enlightenment.org/D327
This happen because proxy was already freed and we try print some information
about the proxy in error message.
This fix: https://phab.enlightenment.org/T543
From D-Bus documentation:
http://dbus.freedesktop.org/doc/api/html/group__DBusBus.html
dbus_bus_register():
If you open a bus connection with dbus_connection_open() or
dbus_connection_open_private() you will have to dbus_bus_register()
yourself, or make the appropriate registration method calls yourself.
Signed-off-by: Eduardo Lima (Etrunko) <eduardo.lima@intel.com>
eldbus_address_connection_get() and eldbus_private_address_connection_get()
are similar to the respective _connection_get() counterparts, but enables
users to connect to buses other than system or session.
The new type introduced for those connections is ELDBUS_CONNECTION_TYPE_ADDRESS
and they require an additional address parameter, which will be passed to
dbus_connection_open().
Signed-off-by: Eduardo Lima (Etrunko) <eduardo.lima@intel.com>
This is actually a split on the _eldbus_connection_unref() function, that
will be called either when the refcount reaches 0 or to force the deletion
of an Eldus_Connection.
The second use case will be contemplated in a following patch.
Signed-off-by: Eduardo Lima (Etrunko) <eduardo.lima@intel.com>