The value must be given to eina_value_set and not a pointer to a
Eina_Value.
This bug results in always getting wrong exit code when the application
terminates.
[Dereference after null check]
(1) src/lib/ecore/ecore_main.c
- _efl_loop_handler_efl_object_finalize checks if pd->loop_data is NULL.
After that, _handler_reset > _handler_clear > _ecore_main_fd_handler_del >
_ecore_main_fdh_pool_del is directly dereferencing pd->pool_data.
- _efl_loop_handler_efl_object_parent_set checks if pd->loop_data as well.
Then it calls _handler_reset as well.
(2) src/lib/ecore_wayland/ecore_wl_dnd.c
- ecore_wl_dnd_selection_set checks if t - result of wl_array_add - is NULL.
And it is dereferecing t directly for wl_data_source_offer.
(3) src/lib/elementary/efl_ui_dnd.c
- Third parameter const char *data could be NULL.
In this case strlen dereferences NULL. The data should be non NULL value.
I have checked this with Mr. Thiep Ha.
(4) src/lib/evas/canvas/evas_object_inform.c
- _efl_canvas_object_efl_gfx_stack_stack_below checks if obj->layer is NULL.
So it could call evas_object_inform_call_call_restack which is dereferencing
obj->layer directly.
so the MAIN loop is actually an efl.app object. which inherits from
efl.loop. the idea is that other loops in threads will not be efl.app
objects. thread on the creator side return an efl.thread object.
inside the thread, like the mainloop, there is now an efl.appthread
object that is for all non-main-loop threads.
every thread (main loop or child) when it spawns a thread is the
parent. there are i/o pipes from parnet to child and back. so parents
are generally expected to, if they want to talk to child thread, so
use the efl.io interfaces on efl.thread, and the main loop's elf.app
class allows you to talk to stdio back to the parent process like the
efl.appthread does the same using the efl.io interfaces to talk to its
parent app or appthread. it's symmetrical
no tests here - sure. i have been holding off on tests until things
settle. that's why i haven't done them yet. those will come back in a
subsequent commit
for really quick examples on using this see:
https://phab.enlightenment.org/F2983118https://phab.enlightenment.org/F2983142
they are just my test code for this.
Please see this design document:
https://phab.enlightenment.org/w/efl-loops-threads/
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.
if its a non-legacy loop handler that also binds an fd handler
internally (the 2 things are linked as a pair) then on loop del, dont
del the objet as the obj del should handle things elsehwere.
odd - i found ecore fd handlers basically ignored hangups from the
other end so we never knew if the other end went or not... crazy. now
we at least have all the read/write/error flags on and the next read
should fail indicating the broken pipe etc. ...
@fix
Summary:
This patch checks for the valid Ecore_Fd_Handler_Flags.
The flags should be checked like previous verion because
There are no default handlings in case of out of Ecore_Fd_Handler enum values in other funcs.
Test Plan: Execute a test case
Reviewers: cedric, raster, jpeg, stefan, Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5775
Summary: This patch fixes a tentative crash owing to dereference of fd_handler.
Test Plan: Execute test suite
Reviewers: cedric, raster, stefan, Jaehyun_Cho
Reviewed By: Jaehyun_Cho
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D5754
so loop object destruction was clearing out fd handlers but those may
be later deleted by destructors of child objects. so leave legacy
fdh's and just remove them from the list
There is no good reason to not shutdown a library properly. The loop
object can easily be deleted safely, if it is properly initialized. The
del event happens before destruction so it is too early to set the
singleton variable to NULL. Do that as late as possible and all calls to
efl_loop_main_get() will work as expected.
The issue with fd's was simply that they were not initialized to -1
(timer_fd), as some #ifdef statements have disappeared.
we really should have data inside the loop object, so begin moving it
one small thing at a time. this is the basics that will allow multiple
efl loops. make an eo efl object and class for fd handlers that is efl loop
bound make fd handlers really bound to their parent loop and not global as
well as have a nice class/obj. create an message queue per loop and
put legacy ecore events on top of it... and a lot more.
this is not 100% done, but it's a lot of the core and groundwork.
various ecore_timer_add(), ecore_diler_add() etc. need changes.
The following still need doing:
ecore_timer (internal usage for sure)
ecore_idler (internal usage for sure)
ecore_idle_enterer
ecore_idle_exiter
ecore_pollers? (is the new efl loop stuff ok?)
ecore_exe (fork/spawn from any thread and track exe from that thread?)
ecore_signal code
ecore_throttle (should we have a single global too? we have per loop)
ecore_app ? (should every loop be given its own argv/argc?)
Lots of internal ecore code uses/calls these legacy calls and we
should have efl loop replacements and/or use the ones we have
The following will bedifferently designed for loop to loop
control/messaging/ipc:
ecore_thread
ecore_pipe
Summary:
GCC4 support compound literals for static initializers only in C89. This
commit reverts to the previous behavior when using this version.
Currently we are using it to build on Windows.
Reviewers: felipealmeida, cedric, barbieri
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D5518
Call provider_find on the loop (or basically any object) with the
color/text/size class interface instead, to find it. The main loop is
the main holder of those objects.
Note: This makes use of provider_find instead of direct access to the
variable, in order to self-test the code. In theory release builds will
not do this and user directly the variable.
After ecore_shutdown the main loop is dead, so the flag do_quit can be
safely reset to 0. This will fix issues with cycles of
elm_init/shutdown. This fixes:
CK_FORK=no tests/elementary/elm_suite elm_win
This patch relies on a few of the previous patches which ensure that
ecore is well shut down.
@fix
Function declared in a .eo are something that we want to allow people to inherit from
or use in a binding. I can't think of a situation where that would be the case for
this function and it solves at the same time problem of needing a shared interface
for both loop and loop_user.