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
It's better than nothing, I don't know what the proper fix is.
FRIBIDI_CFLAGS just doesn't exist. Doesn't that macro we use call
PKG_CHECK_MODULES?
SVN revision: 81385
In ecore_wl_init(), adding wayland display fd with ECORE_FD_WRITE
flag make CPU usage 100%. The proper way to monitor the ECORE_FD_WRITE
is when the wl_display_flush() return value < 0 and errno == EAGAIN.
And if wl_display_flush() return, we remove ECORE_FD_WRITE flag from
the display fd.
Change from v1:
Add idle enterer destroy code into _ecore_wl_shutdown() to avoid
using freed wl_display.
SVN revision: 81360
Leandro Pereira
Tomas Cech
Jihoon Kim
Mike McCormack
Stefan Schmidt
Lucas De Marchi
José Roberto de Souza
Gustavo Sverzut Barbieri
Jonas M. Gastal
Daniel Zaoui
Leandro Dorileo
Paulo Alcantara
Tom Hacohen
Carsten Haitzler
Christopher Michael
Christopher Michael
Yakov Goldberg
Vincent Torri