conversion to efl.nmet didnt deal with null/0 zised payloads properly
and tried to send them, resulting in lots of ERR complaints which were
not errors. fix that to not try and send such empty payloads
@fix
it wasn't looking at the copier queue "todo" at all thus skipping it
on flush. this will fix flushing of ecore ipc message buffers. this
happens to also now fix terminology's "one process" mode.
@fix
This reverts commit 135154303b.
Revert "efl: move signal events from efl.loop to efl.app"
This reverts commit 3dbca39f98.
Revert "efl: add test suite for efl_app"
This reverts commit 3e94be5d73.
Revert "efl: create Efl.App class, the parent of Efl.Loop"
This reverts commit 28fe00b94e.
Go back to before efl.app because I think this should be done with
superclassing here not a parent object. reasons?
1. multiple loops per single thread make no sense. so if multilpe loop
objects they wont be contained in a single app object and then deleted
like this.
2. the app object is not really sharable in this design so it cant be
accessed from other threads
3. it makes it harder to get the main loop or app object (well 2 func
calls one calling the other and more typing. it is longer to type and
more work where it is not necessary, and again it can't work from
other threads unless we go duplicating efl.app per thread and then
what is the point of splittyign out the signal events from efl.loop
then?)
etc.
by deleting the socket they wont mutually exclude at bind which means
eny new server just nides the pror one and you can get lots of copies
of the same server. this wasnt the case before. it shouldnt have been.
i think ther was an rm path for stale sockets when connecting failed
or something. anyway... this here was causing multilpe efreetd's and
all sorts of nastiness. this is the root cause. so... fix it.
@fix
An old comment mentioned that this was explicitely not unregistered, but
I believe the comment isn't valid since ecore_event_type_flush() was
introduced.
This patch sets some Ecore_Con flags that were missing after
the EO migration. These flags must be set in order
maintain the Ecore_IPC behaviour before Ecore_Con EO was implemented.
Fixes T5722
Some applications will create the handle, immediately send data, flush
and delete it, expecting the data to be sent to remote peer.
This is a bad behavior as the application would become unresponsive
until the connection is established, data can be written (since
depends on server consuming it), then allow it to be closed.
A proper behavior here would be to chain based on events, with the
usage of a copier would be simply wait for "done" event.
However the legacy API allowed this and terminology depends on this
awkward "feature", thus be bug-compatible.
This fixes T5015.
In the old/legacy API the socket would be opened early in non-blocking
mode (connect returned errno==EINPROGRESS), with UNIX socket being
path-validated early and returning NULL as 'server' handle.
Some applications relied on this instead of monitoring the "ERROR"
events, considering the connection to be successful if there was a
handle -- this was the case with Terminology after it moved from DBus
to Ecore_Ipc.
Although this is not correct, we must keep compatibility and thus we
stat() in compatibility layer, failing early as the old API would do.
These legacy API had the nasty behavior of keeping handles alive until
the pending events were dispatched, this could happen after the module
itself was shutdown, resulting in log to unregistered domains.
Then do not unregister the domain -- eina_shutdown will avoid leaks
anyway.
I always got this during the build:
lib/ecore_ipc/ecore_ipc.c:537:6: warning: ‘old_mask’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
Looking at the code it really is a false positive. Gettign the mask is behind
an if it is the same if condistion used before writing it. Anyway, silencing the
warning here.
The may_block parameter is useful to force a flush without blocking on
read/write, sometimes particularly useful if ignore_line_delimiter is
true, then you get the data events without blocking -- as if a server
sending some content misses a trailing line delimiter, you do not want
to block on recv() but still want to flush data to user.
The ignore_line_delimiter parameter is useful if we're going to close
the copier and want to flush pending data which may exist due missing
trailing terminator. The close method will also force that if
destination can take more data.
Each client (Ecore_Ipc_Client) is very similar to the handle
configured by ecore_ipc_server_connect() (the dialer), except we do
not have events such as "connected" and "error", as well as we don't
delete the socket as it's owned by the server, instead we close it.
The UNIX socket is configured similarly to ecore_con, setting the same
masks and mode for directories.
Use the new Efl.Net.Dialer classes to implement
ecore_con_server_connect() scenario.
Note that since Windows still doesn't provide any equivalent to
Efl.Net.Dialer.Unix, we keep the legacy code for it.
Using the ecore_ipc_server_example with -m/--single-message, if we
deleted the client from the callback it would find a dead "cl".
As the "cl" handle is removed from svr->clients before it's deleted,
it's safe to check if we have that handle in the list before
proceeding.
The flag 'delete_me' is set when there are pending events to be
dispatched. Once these events are freed, they will check if the server
was pending delete and call ecore_ipc_server_del() again, thus we must
not return, otherwise data will be leaked.
Summary: During mobile product testing, we got a crash with callstack which suggest server is getting deleted prior to client. On valgrind analysis we found invalid write operation with same callstack. callstack is pasted in comment section.
Test Plan: create a situation where server got deleted prior to client.
Reviewers: raster, cedric
Subscribers: govi, rajeshps, jpeg
Differential Revision: https://phab.enlightenment.org/D4152
Summary:
buf is always NULL (already freed and set to NULL).
We don't need to add NULL checking and free it.
Reviewers: raster, cedric, Hermet
Subscribers: seoz, cedric
Differential Revision: https://phab.enlightenment.org/D2783
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary: The allocated memory is not released before return.
Lost track of the CID.
Test Plan: Run static analysis tool such as prevent
Reviewers: raster, cedric
Reviewed By: cedric
Subscribers: cedric, seoz
Differential Revision: https://phab.enlightenment.org/D1746
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
According to clang static analyzer it is possible to find a path where
buf and svr->buf are pointing to the same array, better be safe than sorry.
Arguably this code could be more readable if it was using Eina_Binbuf.
freeing first) leaks the storage that buf Did point to (which could
have been from a realloc above).
NB: Fixes Coverity CID1039277, CID1039278
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Cedric BAIL
Carsten Haitzler
Mike Blumenkrantz
Jean-Philippe Andre
Guilherme Iscaro
Gustavo Sverzut Barbieri
Stefan Schmidt
Jee-Yong Um
Prince Kumar Dubey
Amitesh Singh
Thiep Ha
Shinwoo Kim
Cedric Bail
Chris Michael
Chris Michael