Mostly unused vars following the removal of eo_do_ret().
However, there are some cases where the migration script got some things
wrong, and I had to manually fix them.
I just ran my script (email to follow) to migrate all of the EFL
automatically. This commit is *only* the automatic conversion, so it can
be easily reverted and re-run.
IPV6_ADD_MEMBERSHIP does not exist on OS X, and seems to be obsolete,
according to my glibc's bits/in.h.
IPV6_JOIN_GROUP, however, exists on both.
@fix
Summary:
Changed ecore_con_connector.eo to efl_network_connector.eo as part of
migrating to efl_network.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3427
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
The client structure holds a file descriptor, which is not initialized (which means 0) in case of UDP as there is no client-specific socket.
However, we check for the file descriptor being positive before closing it in the client destructor, which means that we actually end up closing the 0 file descriptor.
That means that things were going crazy with real strange things happening afterwards…
if the object has been deleted already, scope data is null. handle it
correctly. this fixes a segv in the new efreetd when it starts and
there is an existing efreet running thus owning the socket fails.
@fix
Since the move to Eo, in case of error we do not need to cleanup anything when
finalize finish. The kill function was arranged to do so, but it was still emiting
an event exposing the invalid Eo object. Looking closely at the code, that should
have not happened, as there was no symetrical ADD event and the function would do
nothing else. So removing it. This prevent any potential SEGV from a function that
would catch the DEL event.
@fix
From now on, constructors should return a value, usually the object
being worked on, or NULL (if the constructor failed). This can also
be used for implementing singletons, by just always returning the same
object from the constructor.
This is one of the final steps towards stabilizing Eo.
@feature
Summary:
When executed ecore_con_lookup_example function, we were getting a crash. This is the fix for the crash. I analysed it in the valgrind and found the error. Valgrind reported invalid free at this place.
svr->name is getting freed in _ecore_con_server_eo_base_destructor function and svr is getting freed in ecore_con_shutdown function.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2398
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
If the socket is local, then there is no need to through error if the port is less than 0 (i.e., negetive). The behavior is same in _ecore_con_connector_eo_base_finalize funtion. So applied the same here. There is code in ecore_con_local.c to handle if port is less than zero for local sockets.
In _ecore_con_connector_eo_base_finalize function, I've added a space just so that it shows difference in phabricator and would be easy for you to review.
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2089
Summary:
ecore_con_local doesn't currently require any initialization, but it might need
that on some platform and not having the init make the source code non obvious.
This is just a patch to improve future maintenability.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2098
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary: When ecore_init failed or when failed to initialize ecore_con_log_domain, then evil_shutdown was not called. So cleaned up code and added the fix.
@fix
Reviewers: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1921
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
_ecore_con_init_count should not go below zero. I've added a test case to test this and also the code to fix this.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1603
If connect() returns 0, we must send the ECORE_CON_EVENT_SERVER_ADD event
because it wont be given by select(). select() will ONLY notice it if connect
returns -1 with errno set to EINPROGRESS.
This bug is reproductible with 100% chance using ecore_con_telnet_client example
from https://github.com/gfriloux/examples if you connect to 127.0.0.1 instead of
of an external network ip, under FreeBSD (and likely any BSD).
Seems very rare to trigger it under GNU/Linux as it seems that connect()
doesnt want to return 0 when having non blocking sockets (or is too slow),
but it seems i was having this bug too on production servers, without being
ever able to reproduce it.
Summary:
If the function jumpes to the error, the scope data is freed, this is
wrong, just the object should be destroyed, so not free, just eo_unref
the object. Cause the object is just added above the object ref count
should get 0 and obj will get removed
Test Plan: Use the ecore_con_server_client_limit_set function and set the max count to 1, at the connect of a second client the server will fail at this free.
Reviewers: tasn
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1459