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
file_offset_bits .. CHANGES the size of structs like dirent? so if u
do it differently in different c files... u end up with.. GASP
different structs with different sizes! dont do this. unify everything
into eio_private.h so its at least CONSISTENT for eio's internals.
SVN revision: 53322
I needed to bump minor file format version, but it will only
change behaviour for people using alias for part and they
couldn't use the signal emitted by them.
SVN revision: 53305
a super-simple (but full featured) pong game, fully written in embryo,
in the style of the original game.
To run it, like all the other examples, just go in the doc/examples folder and do:
edje_cc embryo_pong.edc && edje_player embryo_pong.edj
Have fun ...beating the ""AI"" is really difficult ;)
SVN revision: 53278
Depending on the option being set by curl_easy_setopt, a return value
different from CURL_OK can be returned (the same applies to curl_multi_*
and CURLM_OK).
This commit checks the return value from those calls and usually
displays an error message with ERR() and returns -- in some cases, an
error is shown but the function does not immediately return.
A few lines of code have also been moved around in order to make
returning from functions as harmless as possible.
By: Raphael Kubo da Costa <kubo@profusion.mobi>
SVN revision: 53275
By checking for the validity of the Ecore_Con_Url struct before anything
else and merging some if's, the code can get much cleaner.
By: Raphael Kubo da Costa <kubo@profusion.mobi>
SVN revision: 53274