crashes for me in expedite with 4 cores on x86 at random points. looks
like it's bitrotting. though it was relatively tentative to begin with.
SVN revision: 53856
This signature change follows libcurl's behaviour more closely:
CURLOPT_POSTFIELDSIZE expects a long, and a value of -1 means that
content length calculation is forwarded to libcurl, which performs a
strlen() on CURLOPT_POSTFIELD.
SVN revision: 53845
- custom pipelines are gone, remove from src/lib/Makefile.am
- no need to check for ffmpeg/cdda anymore, they are handled by playbin2
SVN revision: 53837
Use EINA_INLIST_CONTAINER_GET instead of cast to
(Evas_Preload_Pthread_Worker*) to get eina_inlist_remove's return.
This works even if the first field of Evas_Preload_Pthread_Worker is no
longer a EINA_INLIST
Patch by: Fabiano Fidêncio <fabianofidencio@gmail.com>
SVN revision: 53826
*all struct members are aligned and spaced
*all post-function macros are force-spaced
*all post-function macros are parsed
*all macro definitions are backslash aligned
SVN revision: 53775
add native win32 mutex code.
Question: with pthread, if a mutex is initialized with
PTHREAD_MUTEX_INITIALIZER, should it be destroyed with
pthread_mutex_destroy() ?
SVN revision: 53772
lots of formatting cleanups
move udev extern into private header
another filter added to find_by_type to avoid some disks that randomly crop up with MOUNTABLE
SVN revision: 53745
Description of changes / revisions (not all of them, I just picked some to
explain the names inclusions)
bdilly
Bruno Dilly <bdilly@profusion.mobi>
edbus -> r42081, r39884, r44581, r40463
python-elementary -> r52765, r52389
edje -> r46548, r49242
editje -> r52520
fidencio
Fabiano Fidêncio fidencio@profusion.mobi
elementary / python-elementary -> fix elm_<widget>_{icon,content}_set - r49706;
add externals - r{47649,47647,47645}
edje / python-edje -> lot of work on edje_edit
glima
Gustavo Lima Chaves <glima@profusion.mobi>
elementary -> added widgets
edje -> lot of work on edje_edit
helen
Helen Fornazier <helen.fornazier@profusion.mobi>
elementary -> elementary key events on widgets
editje -> undo / redo
jprvita
João Paulo Rechi Vita <jprvita@profusion.mobi>
e_dbus-> r47399 , r47398, r47397, r47336, r47330
padovan
Gustavo F. Padovan <padovan@profusion.mobi>
e_dbus-> r46365-r46373, r47114-r47119
SVN revision: 53682
This is an attempt to fix the epoll/fork() issue reported to me where
we end up with a single epoll fd shared between two processes after a
fork() in E.
I've tested with elementary test in epoll and non-epoll combinations,
and all appears to be well. Please check it solves the issue you saw,
and reformat the code as you see fit... ;-)
SVN revision: 53670
I don't expect anything to break, but if mouse or keyboard events suddenly
disappear, feel free to revert this patch while blaming cedric or discomfitor.
SVN revision: 53583
Patch by Patch by Raphael Kubo da Costa <kubo@profusion.mobi>
As discussed on the development mailing list, we should accept a
double instead of a time_t for consistency with the rest of the API.
Some apidox has been added too, and as a result
ECORE_CON_URL_TIME_LASTMOD has been removed, since it does not make
much sense (it is an HTTP response header).
SVN revision: 53572
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