when trying to free the mode_info. Not much functional difference with
this commit except that we do not call strndup if the nameLength is
<= 0.
SVN revision: 53477
move or resize of an obj WHILE in the middle of a move or resize
already - some weird case someone has come up with where this happens
and things like smart clipped's "move relatvie by dx, dy" totally
screw up then. it's a totally unexpected case though. some circular
action has been created that logically shouldn't have existed.
SVN revision: 53434
When we push a memory to the trash stack we mark it as unaccessable. So we
should mark it as accessible before returning it to the user.
SVN revision: 53427
Because mempools generally allocate a big memory area and distribute chunks of
that area to the users, valgrind can not know about logical invalid access. By
using some valgrind macros we can tell valgrind about mempools and which area
can be accessed or not.
To start with I have just done valgrind integration on chained mempool but soon
it will be done for one_big too.
The code below is an example on which valgrind wouldn't complain without this
patch:
@code
#include <Eina.h>
int
main(int argc, char *argv[])
{
int i, *pool[4];
Eina_Mempool *mp;
eina_init();
mp = eina_mempool_add("chained_mempool", "test", NULL, sizeof(int), 4);
for (i = 0; i < 4; i++) {
pool[i] = eina_mempool_malloc(mp, sizeof(int));
*pool[i] = i;
}
printf("Valid mp pointer: pool[0] = %d\n", *pool[0]);
eina_mempool_free(mp, pool[0]);
printf("Freed mp pointer: pool[0] = %d\n", *pool[0]);
for (i = 1; i < 4; i++)
eina_mempool_free(mp, pool[i]);
eina_mempool_del(mp);
eina_shutdown();
return 0;
}
@endcode
SVN revision: 53405
match ecore_thread_feedback_run better.
NOTE: I know it breaks API/ABI compatibility for that call,
but that's the only sane solution I could found.
SVN revision: 53370
I was still reaching uninitialized usage and it does make sense, as
the parent thread could be postponed until the new is started, then
the scanner/worker thread hits an error (ie: directory permission
denied) and it is cancelled before the main thread had time to get the
thread attribution (common->thread).
I'd like someone to look at it. Probably this is NOT the right way to
fix. Likely what we should do is send a "ready! start working" command
from the main thread to the worker thread and avoid such thing.
==5848== Conditional jump or move depends on uninitialised value(s)
==5848== at 0x42808CD: ecore_thread_cancel (ecore_thread.c:534)
==5848== by 0x4238558: eio_file_thread_error (eio_single.c:35)
==5848== by 0x42368FC: _eio_file_direct_heavy (eio_file.c:78)
==5848== by 0x42800F3: _ecore_feedback_job (ecore_thread.c:247)
==5848== by 0x4280398: _ecore_thread_worker (ecore_thread.c:317)
==5848== by 0x41FE16AE: start_thread (in /lib/libpthread-2.11.2.so)
==5848== by 0x41F3295D: clone (in /lib/libc-2.11.2.so)
==5848== Uninitialised value was created by a heap allocation
==5848== at 0x400793F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==5848== by 0x4237991: eio_file_direct_ls (eio_file.c:566)
==5848== by 0x8051C81: ephoto_directory_thumb_add (ephoto_directory_thumb.c:131)
==5848== by 0x804D4AB: _ephoto_thumb_dir_icon_get (ephoto_thumb_browser.c:75)
==5848== by 0x405F4C8: _item_realize (elm_gengrid.c:807)
==5848== by 0x405FE77: _item_place (elm_gengrid.c:980)
==5848== by 0x40610F6: _pan_calculate (elm_gengrid.c:1199)
==5848== by 0x418CA38: evas_call_smarts_calculate (evas_object_smart.c:843)
==5848== by 0x41B23B2: evas_render_updates_internal (evas_render.c:971)
==5848== by 0x41B3DA1: evas_render_updates (evas_render.c:1414)
==5848== by 0x42E4550: _ecore_evas_x_render (ecore_evas_x.c:406)
==5848== by 0x42DDD2C: _ecore_evas_idle_enter (ecore_evas.c:47)
SVN revision: 53340
==17972== Use of uninitialised value of size 4
==17972== at 0x42918DB: ecore_thread_cancel (ecore_thread.c:536)
==17972== by 0x4249558: eio_file_thread_error (eio_single.c:35)
==17972== by 0x42478FC: _eio_file_direct_heavy (eio_file.c:78)
==17972== by 0x42910F3: _ecore_feedback_job (ecore_thread.c:247)
==17972== by 0x4291398: _ecore_thread_worker (ecore_thread.c:317)
==17972== by 0x41FE16AE: start_thread (in /lib/libpthread-2.11.2.so)
==17972== by 0x41F3295D: clone (in /lib/libc-2.11.2.so)
==17972== Uninitialised value was created by a heap allocation
==17972== at 0x400793F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==17972== by 0x4248991: eio_file_direct_ls (eio_file.c:566)
==17972== by 0x8050B8E: ephoto_directory_thumb_add (ephoto_directory_thumb.c:127)
==17972== by 0x4061570: _item_realize (elm_gengrid.c:807)
==17972== by 0x4061E27: _item_place (elm_gengrid.c:980)
==17972== by 0x4062875: _pan_calculate (elm_gengrid.c:1199)
==17972== by 0x419DA38: evas_call_smarts_calculate (evas_object_smart.c:843)
==17972== by 0x41C33B2: evas_render_updates_internal (evas_render.c:971)
==17972== by 0x41C4DA1: evas_render_updates (evas_render.c:1414)
==17972== by 0x42F5550: _ecore_evas_x_render (ecore_evas_x.c:406)
==17972== by 0x42EED2C: _ecore_evas_idle_enter (ecore_evas.c:47)
==17972== by 0x428C85F: _ecore_idle_enterer_call (ecore_idle_enterer.c:129)
SVN revision: 53336
<discomfitor> ecore_con_url.c:963:14: warning: too few arguments for format
<rakuco> ah, missing a , filename there
<rakuco> can you commit that
SVN revision: 53334
Mike Blumenkrantz
Christopher Michael
Iván Briano
Carsten Haitzler
Rafael Fonseca
Cedric BAIL
Davide Andreoli
Tom Hacohen
Lucas De Marchi
Vincent Torri
Gustavo Sverzut Barbieri