The _request_failed() function is called by error responses from slaves,
and iterating over references of a entry and removing each of them must
be done with EINA_LIST_FOREACH_SAFE(), since _entry_free_cb() calls
_entry_reference_del() which then removes the reference that is used in
the next iteration in for-loop from _request_failed().
Signed-off-by: Paulo Alcantara <pcacjr@profusion.mobi>
SVN revision: 81580
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
prevent eventual bugs.
Feel free to ask, comment, modify this tutorial.
My last commit before the end of the world.
Signed-off-by: Daniel Zaoui <daniel.zaoui@samsung.com>
SVN revision: 81425
This function was basically never working correctly. Everything was
fixed by simulating the evas_object_image_render() workflow, but
instead of actually draw we just check the pixel transparency.
Bugs fixed:
* fails when image is scaled up (could segv) or down (incorrect values);
* fails when image is moved to negative x,y;
* fails when border was being used.
Now everything is fixed and seems to work properly, except I'm not
handling the map and get_pixels() cases, these are marked with ERR()
so we can fix them if someone needs.
SVN revision: 81410
Whenever we copy an image, making it write-able
(evas_object_image_data_get(o, 1)) or just start painting a pristine
buffer (evas_object_image_size_set(o, w, h)), we must mark the image
as loaded to avoid trying to load it (and failing, marking the whole
thing as EVAS_LOAD_ERROR_GENERIC).
SVN revision: 81409
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