This way we get a spurious line in configure, resulting in this message:
/home/lucas/p/edbus/configure: line 14196: ecore: command not found
SVN revision: 81495
Fix the function and add support for complex types, in which case a
Eina_Value is expected.
Patch by: José Roberto de Souza <zehortigoza@profusion.mobi>
SVN revision: 81493
If we are freeing a EDBUS_Connection_Name its name_owner_changed signal
handler may hold a pointer and try to unref it when deleting the signal
handler. We can't simply make the signal handler hold a reference to the
connection name, otherwise edbus_connection_name_gc will never be
triggered because of cyclic references.
Thus, just set the cn->name_owner_changed->bus to NULL before trying to
delete the signal handler.
Related log found by Lucas Jóia:
==20607== Invalid read of size 4
==20607== at 0x6FE29EE: edbus_connection_name_gc.isra.3 (edbus_core.c:375)
==20607== by 0x6FE4287: edbus_connection_unref (edbus_core.c:1028)
==20607== by 0x4C8D94: e_msgbus_shutdown (e_msgbus.c:167)
==20607== by 0x436194: _e_main_shutdown (e_main.c:1136)
==20607== by 0x434F25: main (e_main.c:1074)
==20607== Address 0x1461ba68 is 24 bytes inside a block of size 64 free'd
==20607== at 0x4C2A739: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20607== by 0x6FF0E78: edbus_signal_handler_unref (edbus_signal_handler.c:269)
==20607== by 0x6FE2A48: edbus_connection_name_gc.isra.3 (edbus_core.c:384)
==20607== by 0x6FE4287: edbus_connection_unref (edbus_core.c:1028)
==20607== by 0x4C8D94: e_msgbus_shutdown (e_msgbus.c:167)
==20607== by 0x436194: _e_main_shutdown (e_main.c:1136)
==20607== by 0x434F25: main (e_main.c:1074)
SVN revision: 81463
Bug triggered by Lucas Jóia:
==10042== Invalid read of size 8
==10042== at 0x6B86626: _eina_rbtree_iterator_next (eina_rbtree.c:165)
==10042== by 0x6B7228D: _eina_hash_iterator_next (eina_hash.c:622)
==10042== by 0x6FE41DC: edbus_connection_unref (edbus_core.c:1015)
==10042== by 0x4C8D94: e_msgbus_shutdown (e_msgbus.c:167)
==10042== by 0x436194: _e_main_shutdown (e_main.c:1136)
==10042== by 0x434F25: main (e_main.c:1074)
==10042== Address 0x15c1b958 is 40 bytes inside a block of size 96 free'd
==10042== at 0x4C2A739: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10042== by 0x6B71CB7: _eina_hash_del_by_hash_el (eina_hash.c:441)
==10042== by 0x6FE2A1E: edbus_connection_name_gc.isra.2 (edbus_core.c:385)
==10042== by 0x6FE4217: edbus_connection_unref (edbus_core.c:1026)
==10042== by 0x4C8D94: e_msgbus_shutdown (e_msgbus.c:167)
==10042== by 0x436194: _e_main_shutdown (e_main.c:1136)
==10042== by 0x434F25: main (e_main.c:1074)
SVN revision: 81462
Case the real part object(rp->object) is an smart object it start to delete
the whole smart object hierarchy and a child object may be a swallow of this
real part. So just delete the rp->object after swallows got handled.
SVN revision: 81403
Signals need to be sent with edbus_service_signal_emit() -- for basic
messages -- or edbus_service_signal_new() + edbus_service_signal_send --
for complex messages. Otherwise it's possible to send signals that are
not in the service introspection or that have different signatures by
mistake/typo.
SVN revision: 81311
having the same argument names in a D-Bus signal/method is the equivalent
in C to have a function with this signature:
int my_func(int a, int a, int a, int a);
Don't.
SVN revision: 81309
Rename these functions since they do not set the data in the
iterator/message but rather they append the data.
Also improve the documentation of edbus_message_iter_arguments_append()
to clarify its usage.
SVN revision: 81295
_object_unregister is called synchronized by libdbus, so when _interface_free() ran
your object its already freed.
==30579== Invalid read of size 4
==30579== at 0x4775190: _find_object_manager_parent (edbus_service.c:803)
==30579== by 0x4775292: _interface_free (edbus_service.c:1011)
==30579== by 0x4777F1D: edbus_service_interface_unregister (edbus_service.c:1101)
==30579== by 0x40CBD28: elm_dbus_menu_delete (elm_dbus_menu.c:128)
==30579== by 0x414552F: _elm_menu_smart_del (elm_menu.c:562)
==30579== by 0x4810F39: _eo_op_internal (eo.c:363)
==30579== by 0x4812E1B: eo_do_internal (eo.c:403)
==30579== by 0x4279D02: evas_object_smart_del (evas_object_smart.c:1080)
Patch by: José Roberto de Souza <zehortigoza@profusion.mobi>
SVN revision: 81180
Keep expected values in a struct. It would be ideal to have all values
and compare functions in an array, so we would be able to set the same
callback function for all methods. But it's already short enough so keep
it as is.
The usage of eina_log here allows us to easily catch which test failed.
SVN revision: 81173
If user passed a string with more elements, return EINA_FALSE on
edbus_message_arguments_get() so he knows not all elements are
initialized. Before this patch, we would notify user of its error if he
did something like:
i) edbus_message_arguments_get(msg, "uu", &a)
ii) edbus_message_arguments_get(msg, "uu", &a, &b)
And "msg" containing only 1 argument.
This also fixes the case in which user is getting the elements of an
array iterator and the array is empty. We were previously returning
EINA_TRUE, even if we were not filling the variable.
Last but not least, if the user was calling
edbus_message_iter_arguments_get() in an empty array, we would return
EINA_FALSE, even if we didn't actually get any element.
SVN revision: 81170
we are only interested in the first char of the signature so we can use
dbus_signature_iter_get_current_type and:
a) avoid the allocation of the signature for each complete type
b) simplify the check for struct and dict, since *_get_current_type()
does TheRightThing (TM)
This also rename some variables to clarify the new semantics:
iter_type -> iter
sig_type -> sig_iter
SVN revision: 81169