* use AC_COMPILE_IFELSE after AC_PROG_CC has been called
* use EFL_CHECK_TESTS after pkg-config has been checked
* enable ecore_evas_extn only if its dependencies are found
SVN revision: 68312
Subject: [E-devel][Patch][ecore_con] Fix invalid curl handle removal by valgrind
Date: Wed, 22 Feb 2012 19:57:36 +0900
Hello,
discomfitor reports bugs by valigrind. I checked it with valgrid and
I found the clues
curl_multi_remove_handle() should not be called when multi handles
being performed. So I removed curl_multi_remove_handle() code from
_ecore_con_url_info_read()
Now, curl_multi_remove_handle() is only called for all easy handles
when a multi-handle ended.
Please review this simple patch.
SVN revision: 68287
NB: These may not be entirely correct, but since I am the only one using
xcb (apparently), and I don't ever use the RandR stuff, they are
sufficient for now. I'll debug them later when I have more time.
SVN revision: 68219
NOTES: It is now safer and faster. I doubt I will have more time before the release to finish
ecore_thread_message_run, nor to make the shutdown nicer.
SVN revision: 68164
Subject: [E-devel] ecore_evas typedef patch src/lib
the attached patch adds
typedef void (*Ecore_Evas_Event_Cb) (Ecore_Evas *ee);
in Ecore_Evas.h and ecore_evas_private.h
Ecore_Evas_Event_Cb is then used within :
ecore_evas.c
ecore_evas_psl1ght.c
ecore_evas_win32.c
ecore_evas_wince.c
ecore_evas_x.c
SVN revision: 68140
SOCKS5 is different from SOCKS4 in that it supports password authentication mechanisms (GSSAPI is still on the todo) and IPV6, neither of which are possible with SOCKS4
NOTE THAT THE CMDLINE SYNTAX FOR AUTOSOCKSING HAS CHANGED!
* ECORE_CON_SOCKS_V4=[user@]server-port:lookup
* ECORE_CON_SOCKS_V5=[user@]server-port:lookup
also note that I did not implement autosocksing with password. it's just not safe.
SVN revision: 67959
Subject: Re: [E-devel] [Patch] ecore_ipc - remove potential risk in
ecore_ipc_shutdown
I found a problem this infinite loop case.
If server is deleted, then ECORE_IPC_EVENT_SERVER_DEL callback
function will be called in client side.
It will happen infinite loop in ecore_ipc_shutdown if
ecore_ipc_shutdown called in this ECORE_IPC_EVENT_SERVER_DEL callback
function.
For example,
server_del_handler =
ecore_event_handler_add(ECORE_IPC_EVENT_SERVER_DEL, _server_del_cb, NULL);
static Eina_Bool
_server_del_cb(void *data, int type, void *event)
{
ecore_ipc_shutdown();
return EINA_TRUE;
}
If server is deleted,
1. _ecore_ipc_event_server_del : svr->event_count++
2. _server_del_cb : ecore_ipc_shutdown called
3. ecore_ipc_shutdown : while (servers) ecore_ipc_server_del(eina_list_data_get(servers))
4. ecore_ipc_server_del : can't eina_list_remove(servers, svr) because event_count != 0
5. infinite loop
I think this while code is very dangerous whether user miss or not.
I modified EINA_LIST_FOREACH_SAFE instead of EINA_LIST_FOREACH refer
to ecore_con.
Please review this patch.
SVN revision: 67874
missing Logfn's. Add handler to free the mouse_move event when we're
done with it. Add a function to retrieve the 'last mouse button down
time' (needed for fixing surface move).
SVN revision: 67781