Summary:
All events must have a type now, otherwise bindings don't know how to handle
the event_info field.
Most of the missing event types were actually "void" (no event_info present).
Some struct definitions had to be moved to eo instead of h files, so they
are available to bindings. Some have not, and are marked with FIXME.
Some namespaces have been fixed (like Efl_Event_Cb -> Efl.Event_Cb).
In general, there are hundreds of changed files, but mostly to add a type which
was not present before, so there's no harm done.
Also, A lot of FIXMEs have been added which should be, like, fixed.
For example, some events can send different types of event_info, which is
very inconvenient (and error prone).
Test Plan: make with c# bindings works, make check and make examples work too.
Reviewers: cedric, q66, lauromoura
Subscribers: zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6169
These events have been removed from efl_object.eo. Bindings can
still use the EFL_EVENT_CALLBACK_ADD and EFL_EVENT_CALLBACK_DEL
events from C, but they won't be available to the bound language.
The rationale is that bound languages probably will have their
own way to handle callbacks and C function pointers will mean
very little to them. For example, the binding code could route
the native callback through a dispatcher so the received
function ptr would always be that of the dispatcher method.
Closes D6179.
Summary:
This is just a wrapper around efl_add_ref() with a NULL parent.
It only simplifies a bit object creation when no parent is desired, but it
simplifies a lot the explanation of the refcounting concepts (and tutorials).
Reviewers: cedric, bu5hm4n
Reviewed By: cedric, bu5hm4n
Subscribers: bu5hm4n, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6024
This changes a lot of things all across the EFL. Previously,
methods tagged @const had both their external prototype and
internal impl generated with const on object, while property
getters only had const on the external API. This is now changed
and it all has const everywhere.
Ref T6859.
Summary:
This commit add null check on __efl_auto_unref_set.
In EO_OBJ_POINTER, if obj_id is null, obj can also be null.
Test Plan: N/A
Reviewers: woohyun, kimcinoo, cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5869
Reviewed-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
This will avoid infinite loops and errors when the parent tries
to orphan an invalidated child.
Fixes T6780
Test Plan: Run `make check`
Reviewers: cedric
Maniphest Tasks: T6780
Differential Revision: https://phab.enlightenment.org/D5839
Reviewed-by: Cedric BAIL <cedric@osg.samsung.com>
This is just a first step. All user of destructor should be updated to
move the code that rely on their efl_parent and on efl_provider_find to
invalidate. Then we will be able to change the way efl_add and efl_del
work to properly refcount things. efl_noref won't be triggered at the
moment until both efl_parent_set(obj, NULL) and the last user ref are
set to NULL. This is not what we want, but due to how user refcount is
accounting parent at the moment, until all the code is move to rely
on invalidate we can not fix this.
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/
The cache had a generation count, removing this check breaks eo suite.
EO is designed to tolerate init/shutdown cycles (as long as
dlopen/dlclose isn't involved).
Note: the ugly goto are useless as GCC -O2 understands EINA_(UN)LIKELY
and deals with it as expected (just look at the asm produced).
See 34d9f20706
This makes eo print a WRN message in case a function is called on NULL.
efl_del is an exception to this rule (implemented in a hackish way, I
admit). I don't know any language or object model where using a null
object doesn't result in an exception or crash, except EO. In any case,
calls to null are invalid.
The next commits will resolve most warnings for EFL.
Ref T6326
Summary:
ecore_evas: remove debug
eina: unregister log level when done with
Fixes a constant memory leak.
eina: introduce EINA_HOT and EINA_COLD
These attributes respectivelly expand to __attribute__ ((hot)) and
__attribute__ ((cold)) when available. They allow to mark functions are
being hot/cold (frequently used or not) as well as to qualify labels
within a function (likely/unlikely branches).
eo: speed-up generated calls by removing call cache
The call cache needed to by thread-local, to avoid concurrency issues.
Problem with TLS is that is adds an extra overhead, which appears to be
greater than the optimization the cache provides.
Op is naturally atomic, because it is an unsigned integer. As such, it
cannot be tempered with while another thread is reading it. When
entering the generated function, the first operation done is reading
'op'. If we have concurrency, we will have access sequences returning
either EFL_NOOP or a VALID op, because 'op' is not set until the very
end of the function, when everything has been computed. As such, we now
use the 'op' atomic integer to instore a lock-free/wait-free mechanism,
which allows to drop the TLS nature of the cache, speeding up the access
to the cache, and therefore making functions execute faster.
We don't test anymore the generation count. This can be put as a
limitation. If means that if you call efl_object_shutdown() and
re-initialize it later with different data, opcodes will be invalid.
I am not sure there is any usecase for this to ever happen.
We could move all the caches in a dedicated section, that can be
overwritten after a call to efl_object_shutdown(), but I am not sure it
will be very portable.
Benchmark: mean over 3 executions of
ELM_TEST_AUTOBOUNCE=100 time elementary_test -to genlist
```
BEFORE AFTER
------------------------------------------------------------
time (ns) 11114111647.0 9147676220.0
frames 2872.3333333333335 2904.6666666666665
time per frame (ns) 3869364.6666666665 3149535.3333333335
user time (s) 11.096666666666666 9.22
cpu (%) 22.666666666666668 18.333333333333332
```
Ref T6580
Reviewers: raster, cedric
Subscribers: cedric, jpeg
Maniphest Tasks: T6580
Differential Revision: https://phab.enlightenment.org/D5738
we can't sensibly use things like massif to track memory if we bypass
itr with mmaping -1 fd anonymous memory... so if built with valgrind
support and running under valgrind, use malloc/calloc and free so
these tools actually do something useful for these bits of memory.
Triggered after (almost) complete destruction of the object.
Not called "deleted" because the other event is already "del".
I don't like "destruct" much but this follows the terminology of
"constructor" / "destructor".
@feature
This reverts commit f910ba248e.
The scheduler is meant to be used only in C, not by bindings so there isn't really
a use for it in the loop class. Now this patch was triggered due to complexity in
using future/promise, so will do a follow up patch to improve that.
Efl.Future is an EO object which means even cancelling Efl.Future
objects requires EO. So this should be done before shutting down EO,
otherwise everything fails badly.
I believe Efl.Future is going to disappear soon, but the problem will
remain: if any promise/future uses EO or anything else outside of Eina
(so, basically anything) then it needs to be canceled before shutting
down the above layers. This is the same situation as with ecore events,
for which we've introduced ecore_event_type_flush.
Ping @cedric
in some cases construction can fail badly and this causes a crash...
eoid is NULL going in and this causes a cascade of failure. survive
and be more robust.
This API is meant to be used by parts only, and by bindings dealing with
part objects. This patch fixes make check which got broken in the after
the previous one (cxx).
luajit wants to check the upper 17 bits of pointers and assume they
are all 0 if on a 64bit architecture. it will panic and barf if they
are used. we have been using them in our eoid's for a long time.
my take on this is that this is unportable. assuming how many bits are
or are not valid in an opaque pointer (void *) that is simply passed
to you and you cannot dereference or use (no size information even for
what amount of data it points to etc.), is just wrong. it's not
portable and it's trying to be too smart and creating such issues. my
take is that luajit needs a fix for this in the longer term. but for
now let's have a 47 bit mode and go with that. it does mean i have to
drop our generation counter to 10 bits on 64bit (from 27 bits) which
increases likelihood of eoid re-use being falsely detected as valid
(before on 64bit it was 1 in 130 million or so chance, with this 47
bit change it's 1 in 1000. but to be fair on 32bit it's 7 bits for gen
count so 1 in 127 ... so still more than 10x "safer" than on 32bit...
but still...). the relevant check in luajit is:
(((uint64_t)(p) >> 47) ? (lj_err_msg(L, LJ_ERR_BADLU), NULL) : (p))
it ONLY does this on 64bit. on 32bit pointers are not checked for
validity at all.
as an aside, armv8.2 seemingly will bring 52bit addresses so luajit is
going to fall over flat on a newer rev of armv8. it may be x86 also
uses more bits. last i knew it was 48bits so the 47 bit check luajit
does i think is even wrong for x86-64. to be detailed i read:
amd64 arch == 48 bits (so luajit is wrong). even better In addition,
the AMD specification requires that the most significant 16 bits of
any virtual address, bits 48 through 63, must be copies of bit 47 (in
a manner akin to sign extension). so if the upper bit of 48 is set
THEN all the 16 upper bits must be 1... breaking luajit, even if it
were 47bit and this rule applied. I read the architecture allows for
up to 52bits of actual addresses so architecture-wise this is even
wrong...
So I smell a core bug here in luajit. Certainly in the number of bits
it insists must be 0 (the upper 17 bits where on amd64/x86-64 it
should be the upper 16 bits... and even then these may NOT be 0 if bit
47 (the upper bit of the lower 48 is 1).... so the whole check is
invalid... :(
at least the above is at a theoretical level. i believe that the
addresses divide the 48 bits into 2 chunks (thus 47)... but at the
PHYSICAL level with no mmu and virtual memory. arm64 has this:
https://www.kernel.org/doc/Documentation/arm64/memory.txt
note in all cases the 2nd chunk of memory has at leats some upper bits
of physical addresses beign 1 ... which makes luajit invalid tyo use
without virtual memory remapping these away from high bits.
@fix
It would be pretty stupid to create an object that dies before it even
gets created. Auto-unref is for parts and should probably not be used
anywhere else :)
the freeq can't allow things to access the content of the pointer
because the content canbe written over by canary handling qhen
submitted to the freeq. clear it inline then just submit the final
pointer to the freeq.
@fix
Before screaming in horror (C++...) here's why we may need this:
Efl.Part.part API returns an object that is by definition valid for a
single function call only. Enforcing this in practice is actually quite
hard as all implementation functions must manually take care of the
life-cycle. This is a lot of code in many places and a lot of
opportunities to forget to properly handle that life-cycle. Also, this
means any invalid function call on a part will leak an object.
This API absolutely must remain either "internal" or "beta" and
definitely not become abused by applications. On top of that such an API
can cause great trouble for bindings like C++. As a consequence, only
specially crafted APIs like efl_part() should return an object marked as
auto_unref.
Alternatively this API could be defined in Eo.h or some other
Eo_Internal.h. I placed it in efl_object.eo because it's much more
convenient :) (read: I'm lazy)
****
Performance notes:
Tested with clang & gcc (with -O2), I had a look at the output of perf
top, in particular the asm view. I used eo_bench in a loop. My
conclusions are:
- EINA_LIKELY/UNLIKELY actually works. The jump statement varies
according to the expectation. I highly doubt all those ugly goto in
eo.c / Eo.h are even useful.
- The impact of auto_unref on a call_resolve is so small it doesn't even
appear in the trace. It is significant inside call_end, though
(obviously, that function is just a few lines long). That function
accounts for ~1% to ~4% of all CPU time. The impact of auto_unref in
call_end is ~4% of the function time. This means ~0.16% of all CPU
time (worst measured case). _efl_object_op_api_id_get simply doesn't
show up because of caching, so the extra check there is negligible.
PS: I also tested EINA_LIKELY/UNLIKELY by compiling with -O2 and looking
at the output with objdump. The flag is well respected, and the jump
instructions are what you would expect (no jump for LIKELY and jump for
UNLIKELY). Conclusion: The goto's in eo.c only make the code harder to
read...
Simply pass in the strbuf and don't expect the callee to own it. This
makes things simpler and safer (it'll crash only if the callee frees
said strbuf, and shouldn't leak). efl_ebug_name is new in the upcoming
release, EFL 1.21.
Realised this after talking with Amitesh. Thanks.
See 999dbd9764
And c4769ff898
there can be cases where the call to such a function is never going to
be directed to the actual implementation. In those cases the FallackCall
will be called.
This allows deleting an object by simply calling efl_unref() on it, even
if there is a parent. Normally the parent is in charge, and you can
request deletion by calling efl_del() or efl_parent_set(NULL).
But in some rare cases, you want to give ownership of an object (@owned)
and still give a parent to that object. efl_unref() should be used (and
would be used by bindings when going out of scope or on garbage
collection), which would then print an error message. This API allows
the specific behaviour.
@feature
export EO_LIFECYCLE_BACKTRACE=0
This means that the lifecycle can be tracked but we don't care about the
backtraces. Related to some recent eo_debug patches.
If an object still has a parent inside the del intercept, we shouldn't
reset the "parent_sunk" flag. This would indeed break logic as
parent_sunk == false implies that a parent was never set, which means
the parent must be null. Right now this case isn't used but it can be
imagined with caches of evas objects (they should remain parented to
their evas).
@fix
efl_data_scope_safe_get() is often used to assert that an object is of a
certain type, but assuming it may be NULL or not of the required type.
This means that encountering an invalid type is an error handled by the
caller (we return NULL), and shouldn't print out extra ERR() logs.
This fixes issues with E run under eo_debug. E's code was safe as it's
using evas_object_smart_data_get() and verifies whether the returned
value is NULL (which is expected for a rectangle, for instance).
@fix
This is done via the syntax (not documented yet):
EO_LIFECYCLE_DEBUG=N:<class names>
Where N is:
1. new/free
2. new/free/ref/unref
3. new/free/ref/unref/reuse
@feature
It's not enough to check the init generation count, if the cache data is
not reset properly.
This patch adds safety in two ways:
1. Actually reset the op call cache when we detect a new generation
2. Verify that we don't return NULL function pointer
The 1st point is absolutely necessary, 2nd is optional (extra cost of
one if()).
@fix
It's a complex struct but defined in EO as a simple struct. ABI-wise
it's equivalent to Eina_Rectangle. Some macros that use Eina_Rectangle
also work on Eina_Rect out of the box, most of the code dealing with
x,y,w,h will require no modifications either.
But Eina_Rect provides direct access to a size or position 2d component,
as well as the usual x,y,w,h. The field "rect" is provided as a
convenience for code dealing with both Eina_Rectangle and Eina_Rect. We
may or may not require it.
Note: Size2D could use unsigned values but I have spotted a few places
in the code that actually use -1 to indicate invalid size (as opposed to
0x0).
@feature
This commit adds the EO support for the new future infra.
From now on there's no need to efl_future_link()/efl_future_unlink()
object and futures since the new API already handles that internally.
There is a problem with the previous version. The object can still be
alive due to the use of manual_free in evas. So you wouldn't be able
for example to remove a callback from an object that hasn't been
destroyed yet. If that callback is triggered by the destruction
of the object, you would end up with an unexpected and impossible to
prevent effect of access after free on a callback that you had removed.
Not sure if that still solve the original problem that the code was
trying to prevent in Ecore_Evas.
This makes sure the object is actually still alive and kicking before
returning any data. Otherwise the "safe" word is a bit of an abuse...
Ref T5869
@fix
In some case, detected during eo test suite, the vtable does fail to
be fully assigned, but it is still being assigned as the new vtable.
Of course when later destroying it, it has already been freed. Leading
to a double free.
This will include the following information, by default:
- class name
- whether the class is an override
- eo id (pointer)
- refcount
- name if one was set (Efl.Object property)
This also supports classes, which is why it's an EAPI in eo.c
and not only a method of Efl.Object
This can be overriden by subclasses using the empty method
Efl.Object.debug_name_override.get
If the function is overriden, then the returned string is used
as is and so it is left to the subclass to include all the
necessary information (as above). This can easily be achieved
by calling efl_debug_name_get(efl_super()) and then concatenating
the strings.
Think of this function as something like Java's toString(), but
only for debugging (i.e. a string class should not just return
its string value).
@feature
This allows two things:
- adding new override functions on an object that already has
overrides
- resetting a specific function (or list of functions) to the
parent class implementation by passing NULL as implementation
Fixes T5580
@feature
Explicit lock / unlock of the shared mutex mixed with implicit
lock / unlock when accessing the internal Eo_Object data lead
to uncaught issues such as these.
This was found by trying to run E with gfx filters under eo_debug.
eo_function(NULL) always leads to a no-operation. A this
point it is basically considered the normal operation
with EO to just silently ignore NULL errors.
If the API function "eo_function" belongs to a class that
has not been loaded yet (eg. no object of this type has
been created yet), then the op associated to the API func
may not be defined yet.
Fixes T5715
This focus on the domain and ID bits is very confusing. Let's
keep it at the end of the message, and also try to guess whether
the object may have been deleted or simply doesn't belong to the
current thread.
This is a safe version of efl_data_scope_get, meaning that it will
return NULL if the object is not of the required type, or if there
is no data for that class, or if the given class was used as an
interface (and isn't a mixin).
@feature
This makes it work like C++ dynamic_cast<> operator, so that
the return value will be NULL if the object is not an instance
of the given class.
In case of efl_super() we don't do it as efl_super is used A LOT
inside EFL itself (all constructors & destructors, for a start)
and efl_isa is in fact a bit expensive. efl_cast isn't really used
and is intended to be something like dynamic_cast.
For @cedric :)
There have been cases where the logic of _event_callback_call break'ed
too early in the event submission.
Reason for that was the line ((const unsigned char *) desc -
(const unsigned char *) it->desc) producing a overflow.
This means the if statement
if (!legacy_compare &&
((const unsigned char *) desc - (const unsigned char *) it->desc) < 0)
was true while the pointer desc was smaller than it->desc, which means
the event subscription got aborted, even if it should not.
This turned out on two 32 bit maschines. And led to not rendering apps
anymore.
It was introduced by commit in 605fec91ee.
@fix
We don't need to keep this in eo files anymore because the APIs
using them are now fully in C. This also allows removal of the
event callback builtin from Eolian.
In a few classes, this requires some manual expansion. This should
not break anything but it's also fairly ugly; a better solution
would be appreciated, for now we do this.
Similar changes will be done to a few other Efl.Object APIs as
well at later point.
This is similar to efl_super but the specified class is the one
we want to call the function on. This is similar to dynamic_cast<>
in C++.
Note: both efl_super() and efl_cast() need documentation!
This is an experimental feature.
Fixes T5311
@feature
Maniphest Tasks: T5311
Differential Revision: https://phab.enlightenment.org/D4797
I've always really disliked this lock. If someone calls a non-eo
function by accident with efl_super() then you'll most likely end
up in a deadlock.
This adds the cur_klass pointer to the object itself, exploiting
the fact that we have 8 bytes of padding (on 64 bits, at least).
Also, this opens the door to efl_cast() which would be similar to
efl_super() except that only a dynamic cast is done, not a call
to the parent function.
make benchmark shows a performance improvement, surprisingly.
This is a bit experimental. See also the following commit (efl_cast)
Summary:
This uses Eina_Cow to implement support for rarely used features
in EO objects. This covers:
- composite objects (eg. UI widgets: combobox, text, video, win)
- vtable for efl_object_override
- del_intercept
All of these features are quite tricky to get right and while
very useful, should still be used with great care. With this patch,
the size of an _Eo_Object struct comes down from 80 bytes (rounded
up from 72b) to 64 bytes (rounded up from 56b) on 64 bits.
Also I haven't measured precisely but I don't expect any performance
impact since the COW data is more likely to remain in L1/L2 cache,
as the default one will be used most often. Unfortunately, the
results of "make benchmark" have been quite inconsistent over
multiple runs.
This saves ~64kb in elementary_test (>4k objects) at the cost of
~100 calls to COW write (del intercept on some events).
@optimization
Reviewers: raster, cedric
Differential Revision: https://phab.enlightenment.org/D4796
If efl_object_override() is called with a function that does
not exist in the original class, it may lead to a crash on
indexing an non-existing array in the vtable.
This is really just a safety check, as the usage was wrong:
* You are only allowed to override functions that are defined in the
* class or any of its interfaces (that is, efl_isa returning true).
Summary:
when a few recursive event emissions are happening, and in some deep
recursive level a subscription to the same object is happening, the
subscription would just be executed when the complete recursion is done.
that is wrong. The subscription needs to be executed when the event is
called after the subscription is added, undepended from any recursive
level. That fixes that and adds a regression test for it.
This was discovered in e, since e gives a lot of error messages about a eo object
that is already freed. It turned out this object is returned from evas, and exactly
the above happened to the EFL_EVENT_DEL subscription of that object.
Test Plan: make check
Reviewers: tasn, cedric, stefan_schmidt
Subscribers: stefan_schmidt, netstar, zmike, raster, jpeg
Differential Revision: https://phab.enlightenment.org/D4656
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
In case of manual free, as is heavily used by Evas, we can't really
print an ERR if there are still references before free has been
called.
This may not be ideal from a pure EO point of view but considering
how Evas uses manual free this is the best solution to avoid
polluting debug logs.
This changes the following message when the object is referencing
its own data. Also lowers from ERR to WRN and adds the class
name for the referenced data.
ERR<17450>:eo /home/jpeg/e/core/efl/src/lib/eo/eo_private.h:337
_efl_unref_internal() in /home/jpeg/e/core/efl/src/lib/eo/eo.c:620:
func '_efl_object_call_end' Data of object 0x400000021008db58 is
still referenced by object 0x400000021008db58
Note that evas and elm have a few calls to efl_data_ref(obj, NULL)
which are imho quite ugly: not using the return value and not
specifying the data class. I'm keeping them as-is for now.
yes - we compare a difference between 2 ptrs and an index which is a
uint. the safe thing here is to promote the unit to the ptrdiff_t
type. reality is we cant have more than 2^32 cb's on an object
anyway... so this should be ok.
Efl.Model.Container and Efl.Model.Item to efl/interfaces are used
to create Efl.Model objects with predefined property values.
This is useful to any situation where we want an Efl.Model with
explicit defined property values.
Efl.Ui.View and Efl.Ui.Factory are used to connect Efl.Models with
Widgets, Elm.Layout and Efl.Ui.Image has changed to use news interfaces
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This condition can never be true. It can't be NULL here. A NULL here
would have caused a crash earlier, though it can only be NULL if an
allocation fails, which is something that we don't really handle
for smallish allocations.
CID1366823
Since we keep a log of created and deleted objects, we can walk the
log and see which were leaked. As this is expensive, do only if log
level is greater than 3 (INFO, DEBUG...), with backtrace of object
creation being displayed as backtrace if running as level 4 (DEBUG).
This fixes an issue where efl_isa() wouldn't work for extensions or
ancestors of extensions of a class.
Example:
Class A implements interface F2
F2 inherits from interface F1
obj is of class A
Before this patch efl_isa(obj, F1) would return false, now it returns
true as expected.
This is just one example, there is a whole array of variations to this
issue that are now fixed.
Thanks to Gustavo for reminding me of this.
@fix
Tom is worried about performance hit (god, checking a bit in a pointer
we'll fetch to memory anyway, since we return it masked), so guard
under EO_DEBUG.
In C we need this to make clear that we really do not accept parameters.
Found by the smatch source code matcher. I had run and fixed this before
but it seems to creep in again over time.
When writing this ERR log I thought about "thread" (it's really
the keyword here) but eventually reworded to "context". Let's be
clearer about the possible issue here.
_efl_object_api_op_id_get() will query a hash for the given pointer,
however if it wasn't populated, it will return "NOOP" and we're
hopeless while debugging on what happened.
Common case is to use the incorrect method, like:
obj = efl_add(CLS1, ...);
cls2_method(obj);
Since we did not create CLS2, it won't populate its methods on the
hash, thus the lookup will return NOOP.
With this change the function now gets the target object and function
name so reports an insightful message such as:
ERR:eo file.c:123 cls2_method() Unable to resolve op for api func 0x7ff492ddea00 for obj=0x400000007e8ee1df (CLS1)
Eo pointer indirection is super nice as it avoids you to access
invalid memory, but this extra checks inhibits valgrind's own tracking
of memory lifecycle, usually it would report when the object was
created and when the object is deleted, both as stack traces.
This commits introduces logging of object creation and destruction
under its own eina_log_domain and controlled by EO_LIFECYCLE_DEBUG and
EO_LIFECYCLE_NO_DEBUG envvars. These will only be available if
compiled with EO_DEBUG, thus shouldn't cause any performance hits on
production code.
Running a bogus app with invalid efl_class_name_get() and double
efl_del() will report as below:
```sh
$ export EO_LIFECYCLE_NO_DEBUG=Efl_Loop_Timer,Efl_Promise,Efl_Future
$ export EO_LIFECYCLE_DEBUG=1
$ export EINA_LOG_LEVELS=eo_lifecycle:4
$ /tmp/bogus_app
DBG:eo_lifecycle lib/eo/eo.c:2712 _eo_log_obj_init() will log all object allocation and free
DBG:eo_lifecycle lib/eo/eo.c:2788 _eo_log_obj_init() will NOT log class 'Efl_Future'
DBG:eo_lifecycle lib/eo/eo.c:2788 _eo_log_obj_init() will NOT log class 'Efl_Promise'
DBG:eo_lifecycle lib/eo/eo.c:2788 _eo_log_obj_init() will NOT log class 'Efl_Loop_Timer'
DBG:eo_lifecycle lib/eo/eo.c:2665 _eo_log_obj_new() new obj=0x563fa35a1aa0 obj_id=0x4000000002cf38ef class=0x563fa35a1450 (Efl_Vpath_Core) [0.0004]
DBG:eo_lifecycle lib/eo/eo.c:2665 _eo_log_obj_new() new obj=0x563fa35af8d0 obj_id=0x4000000006cf38f0 class=0x563fa35aecf0 (Efl_Loop) [0.0005]
DBG:eo_lifecycle lib/eo/eo.c:2665 _eo_log_obj_new() new obj=0x563fa35d61a0 obj_id=0x400000007ecf390e class=0x563fa35d48f0 (Efl_Net_Dialer_Simple) [0.0054]
DBG:eo_lifecycle lib/eo/eo.c:2665 _eo_log_obj_new() new obj=0x563fa35d6470 obj_id=0x4000000082cf390f class=0x563fa35d0d60 (Efl_Net_Dialer_Tcp) [0.0055]
DBG:eo_lifecycle lib/eo/eo.c:2665 _eo_log_obj_new() new obj=0x563fa35d75b0 obj_id=0x4000000086cf3910 class=0x563fa35d66b0 (Efl_Io_Queue) [0.0056]
DBG:eo_lifecycle lib/eo/eo.c:2665 _eo_log_obj_new() new obj=0x563fa35d8f70 obj_id=0x400000008acf3911 class=0x563fa35d7860 (Efl_Io_Copier) [0.0057]
DBG:eo_lifecycle lib/eo/eo.c:2665 _eo_log_obj_new() new obj=0x563fa35df980 obj_id=0x40000000a6cf3918 class=0x563fa35d66b0 (Efl_Io_Queue) [0.0058]
DBG:eo_lifecycle lib/eo/eo.c:2665 _eo_log_obj_new() new obj=0x563fa35dfc30 obj_id=0x40000000aacf3919 class=0x563fa35d7860 (Efl_Io_Copier) [0.0058]
will efl_class_name_get() with invalid handle:
ERR:eo lib/eo/eo.c:1013 efl_class_name_get() Class (0x2000000000000029) is an invalid ref.
ERR:eo_lifecycle lib/eo/eo.c:1013 efl_class_name_get() obj_id=0x2000000000000029 was neither created or deleted (EO_LIFECYCLE_NO_DEBUG='Efl_Loop_Timer,Efl_Promise,Efl_Future').
DBG:eo_lifecycle lib/eo/eo.c:2688 _eo_log_obj_free() free obj=0x563fa35df980 obj_id=0x40000000a6cf3918 class=0x563fa35d66b0 (Efl_Io_Queue) [0.0061]
DBG:eo_lifecycle lib/eo/eo.c:2688 _eo_log_obj_free() free obj=0x563fa35dfc30 obj_id=0x40000000aacf3919 class=0x563fa35d7860 (Efl_Io_Copier) [0.0061]
DBG:eo_lifecycle lib/eo/eo.c:2688 _eo_log_obj_free() free obj=0x563fa35d75b0 obj_id=0x4000000086cf3910 class=0x563fa35d66b0 (Efl_Io_Queue) [0.0061]
DBG:eo_lifecycle lib/eo/eo.c:2688 _eo_log_obj_free() free obj=0x563fa35d8f70 obj_id=0x400000008acf3911 class=0x563fa35d7860 (Efl_Io_Copier) [0.0061]
DBG:eo_lifecycle lib/eo/eo.c:2688 _eo_log_obj_free() free obj=0x563fa35d6470 obj_id=0x4000000082cf390f class=0x563fa35d0d60 (Efl_Net_Dialer_Tcp) [0.0063]
DBG:eo_lifecycle lib/eo/eo.c:2688 _eo_log_obj_free() free obj=0x563fa35d61a0 obj_id=0x400000007ecf390e class=0x563fa35d48f0 (Efl_Net_Dialer_Simple) [0.0063]
will double free:
ERR:eo ../src/lib/eo/efl_object.eo.c:78 efl_del() EOID 0x400000007ecf390e is not a valid object. EOID domain=0, current_domain=0, local_domain=0. EOID generation=2cf390e, id=1f, ref=1, super=0. Thread self=main. Available domains [0 1 ]. Maybe it has been deleted or does not belong to your thread?
ERR:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del() obj_id=0x400000007ecf390e created obj=0x563fa35d61a0, class=0x563fa35d48f0 (Efl_Net_Dialer_Simple) [0.0054s, 0.0009 ago]:
ERR:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del() 0x007f2c0bc6d0ea: libeo_dbg.so+0x90ea (in src/lib/eo/.libs/libeo_dbg.so 0x7f2c0bc64000)
ERR:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del() 0x007f2c0bc6ca62: _efl_add_internal_start+0x1c2 (in src/lib/eo/.libs/libeo_dbg.so 0x7f2c0bc64000)
ERR:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del() 0x00563fa15dc95f: bogus_app+0x295f (in /tmp/bogus_app 0x563fa15da000)
ERR:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del() 0x007f2c0ace7291: __libc_start_main+0xf1 (in /usr/lib/libc.so.6 0x7f2c0acc7000)
ERR:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del() 0x00563fa15dc48a: _start+0x2a (in /tmp/bogus_app 0x563fa15da000)
ERR:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del() obj_id=0x400000007ecf390e deleted obj=0x563fa35d61a0, class=0x563fa35d48f0 (Efl_Net_Dialer_Simple) [0.0063s, 0.0000 ago]:
ERR:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del() 0x007f2c0bc6d8ba: libeo_dbg.so+0x98ba (in src/lib/eo/.libs/libeo_dbg.so 0x7f2c0bc64000)
ERR:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del() 0x007f2c0bc6d711: libeo_dbg.so+0x9711 (in src/lib/eo/.libs/libeo_dbg.so 0x7f2c0bc64000)
ERR:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del() 0x007f2c0bc6beb8: libeo_dbg.so+0x7eb8 (in src/lib/eo/.libs/libeo_dbg.so 0x7f2c0bc64000)
ERR:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del() 0x007f2c0bc6c06e: _efl_object_call_end+0x4e (in src/lib/eo/.libs/libeo_dbg.so 0x7f2c0bc64000)
ERR:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del() 0x007f2c0bc75725: efl_del+0x105 (in src/lib/eo/.libs/libeo_dbg.so 0x7f2c0bc64000)
ERR:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del() 0x00563fa15dcd54: lt-efl_net_dialer_simple_example+0x2d54 (in /tmp/bogus_app 0x563fa15da000)
ERR:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del() 0x007f2c0ace7291: __libc_start_main+0xf1 (in /usr/lib/libc.so.6 0x7f2c0acc7000)
ERR:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del() 0x00563fa15dc48a: _start+0x2a (in /tmp/bogus_app 0x563fa15da000)
ERR:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del() obj_id=0x400000007ecf390e was already deleted 0.0000 seconds ago!
```
if for some reason we fail to validate a class, then we should skip
that extension. This may result in an empty vtable, then check for
that and avoid a crash.
This is very unlike to happen in practice, but I've forced some
validation errors and could get to that.
Instead of 2 sets of macro, one for HAVE_EO_ID and another without,
use a single set of macros and have the implementation of
_eo_class_pointer_get() and _eo_obj_pointer_get() to do the actual
These functions now take the source information so the logs reflect
that and not always the same function.
_eo_pointer_error() was kinda a bitch to debug as it provided a nice
breakpoint location, but did not provide a good output since the file,
line and function were always the same.
Change that to be a thin wrapper on top of eina_log_vprint(), then we
keep the breakpoint location yet provide useful information.
In that sense, change other error messages so they carry as much
information as possible.
This fixes T4907
The problem was that in efl_event_callback_add the internal array was
changed. If this was happening while a efl_event_callback_call was
happening the for loop got confused and skipped one event subscription.
Which led to a bug in e where the idler ufnction was not executed
probebly and so the canvas stayed frozen.
if there is a event the callback counter should be incremented not
decremented. This should fix a few crashes i found in edje, since edje
did not knew that a element was deletion.
Normally when debugging Eo with gdb you can just use any of the internal
eo functions to resolve the id to its internal pointer. However, when
loading a coredump you can't execute any code, not even the id resolve
code.
This change adds a gdb function that resolves the id to its pointer form
without executing any code in the process space. This plugin is
essentially the id resolve code written in python as a gdb function.
Usage:
Print the pointer:
(gdb) print $eo_resolve(obj)
$1 = (_Eo_Object *) 0x5555559bbe70
Use it directly (e.g. to print the class name):
(gdb) $eo_resolve(obj)->klass->desc.name
This plugin requires that the coredump would be loaded with the exact
same libeo.so binary (or at least one that hasn't changed eo internals),
and that the debug symbols for libeo.so would be available for gdb to
use.
Note:
This feature is incomplete and only resolves IDs that are owned by the
main thread and in the main domain. This is not a big issue at the
moment, because almost all of our IDs are like that.
@feature
so hunting another callback issue i noticed some of THE most popular
callbacks are:
1411 tick
1961 move
4157 pointer,move
7524 dirty
8090 damage
13052 render,flush,post
13052 render,flush,pre
13205 render,post
13205 render,pre
21706 recalc
21875 idle
27224 resize
27779 del
31011 idle,enter
31011 idle,exit
60461 callback,del
104546 callback,add
126400 animator,tick
as you can see callback del, add and the general obj del cb's are
right up there... so it is very likely a good idea to CHECK to see if
anyone is listening before calling the callback for these very very
very common calls.
this is ifdef'd and turned on for now. it can be turned off. it
shouldnt use more memory due to the way memory alignment works (likely
all allocations will be multiples of 8 bytes anyway) so we're using
spare unused space. the only q is - is management of the counts AND
checking them worth it in general? it's really hard to tell given we
dont have a lot of benchmarks that cover a lot of use cases... it
doesnt seem to slow or speed anything up much in the genlist bounce
test... so i think i need something more specific.
@optimize
i found a massive slowdown that over time ended up with 10000's of
cb's in objects like the ecore loop object. this fixes that by
ACTUALLY flagging event deletions waiting to be true rather than false.
When resolving a function for an object the object would get reference,
and then in some failure cases won't be freed.
I suspect this is a regression following the reshuffling that was done
in that function recently.
Thanks to zmike for investigating and reporting this.
Fixes T4740
@fix
This happens with shared objects.
The situation seems to be:
1. object has composited object a of class A in thread 1
2. call something on object a from thread 2, deadlock
In fact, do anything from thread 2 on a shared object and you deadlock.
this moves a lot of error case handling into goto's so the code gets
out of the hot path and this should help expecially since variou
smacros do things like:
do { char buf[256]; sprintf(buf, fmt, ptr); _eo_pointer_error(buf); } while (0)
_Efl_Class *klass; \
do { \
klass = _eo_class_pointer_get(klass_id); \
if (!klass) { \
_EO_POINTER_ERR("Class (%p) is an invalid ref.", klass_id); \
return ret; \
} \
} while (0)
so putting quite a chunk of code inside a rare "if this errors"
handler that will cause l1 cache misses and this we don't want, thus
moving stuff in eo core out of hot paths to cut down on overhead. yes
it might not be pretty but it's kind of the right thing at such a core
level of efl. this also does the same to the eo base class as this is
also going to be relatively hot given it's the core of every other
object.
so there were a few issues. one we had a spinlokc on the eoid table
for shared objects AND then had a mutex for accessing those objects
(released on return from any eo function). BUT this missed some funcs
like eo_ref, eo_unref and so on in eo.c ... oops. so fixed. but then i
realized there was a race condition. we locked the eoid table then
unlocked with our pointer THEN locked the sharted object mutex ...
then unlocked it. that was a race condtion gap. so we should share the
same lock anyway - if it's a shared object, grab the shared object
mutex then do a lookup and if the lookup does not fail, KEEP the lock
until it is released by the return from eo function or by some special
macro/funcs that released a matching lock. since its a recursive lock
this is all fine. as its also a universal single lock for all objects
we just need the eoid to know if it's shared and needs locking based
on the domain bits. so now do this locking properly with just a single
mutex, not both a spinlock and mutex and keep the lock around until
totally done with the object. this plugs the race condition holes and
goes from 1 spinlock lock and unlock then a mutex lock and unlokc to
just a single mutex lock and unlock. this means shared objects are
actually truly safe across threads and only have the overhead of a
single recursive mutex to lock and unlock in every api call.
as per other recent benchmarking, moving rearely run code (in this
case code to init the op etc.) out of the l1 cacheline prefetch inot a
blob of code at the end of the function where we goto and goto back
again should provide decent-ish speedups for the resolv cache in
avoding this code. yes it makes the code less pretty to read but at
this really low level hot path ... evil things must happen to get the
speed we want/need.
Summary:
as told in _eina_stringshared_key_cmp in eina_hash.c:
originally we want to do this:
return key1 - key2;
but since they are ptrs and an int can't store the different of 2 ptrs in
either 32 or 64bit (signed hasn't got enough range for the diff of 2
32bit values regardless of their type... we'd need 33bits or 65bits)
So changing this to the same logic.
Reviewers: tasn, raster
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4298
whenan eoid lookup fails, now print a lot of information on the issue
like the actual id, generation of the id, if its a class or object
(the class bit), if its ref or super bit is set, the actual id (which
includes the table heirachy), which thread id it is, what domain the
object id is and the current and local domains as well as what domains
are mapped in.
This change lets us remove a field from the structure that leads to
around 20KiB more of saving in private dirty pages in elementary.
This also looks a bit better and feels a bit cleaner.
Breaks API and ABI.
we now just lost another bit from generation count. down to 6 in 32bit
and 26 in 64 bit. this sucks but is necessary. now we are using the
bits just below ref and super bits the code was just maskign off the
next bit as a class marker. this was so so so so wrong. it was the ide
table space. we just never used numbers high enough to start using it.
since i added domain there now those bits can be used easily with
thread domain or other domain. argh! existing eo bug found and fixed.
annoying! :) i added another #define there just to be clear we use
that bit for classes.
Before this commit, function overrides were explicit. That is, you'd
have to explicitly state you were overriding a function instead of
creating a new one. This made the code a tad more complex, and was also
a bit more annoying to use. This commit removes this extra piece of
information.
This means we now store much less information per function, that will
let us further optimise out structures in the future.
Now that we have recursive locks, the class creation code can be much simpler.
All the code there was essentially our own implementation of recursive locks,
or rather a special case of those.
This is no longer needed.
this adds a signle mutex (recursive) mutex for all eo objects that is
auto-called by _efl_object_call_resolve() and _efl_object_call_end()
that wrap all eo method calls and since its recursive it can be
blindly called for sub-calls. this will lock all shared objects during
any call to any shared object so only the thread calling now has
access until it releases. not fine-grained but good enough and the
best we can do "simplistically".
This moved all the eoid tables, eoid lookup caches, generation count
information ad eo_isa cache into a TLS segment of memory that is
thread private. There is also a shared domain for EO objects that all
threads can access, but it has an added cost of a lock. This means
objects accessed outside the thread they were created in cannot be
accessed by another thread unless they are adopted in temporarily, or
create4d with the shared domain active at the time of creation. child
objects will use their parent object domain if created with a parent
object passed in. If you were accessing EO (EFL) objects across threads
before then this will actually now cause your code to fail as it was
invalid before to do this as no actual objects were threadsafe in EFL,
so this will force things to "fail early".
ecore_thread_main_loop_begin() and end() still work as this uses the
eo domain adoption features to temporarily adopt a domain during this
section and then return it when done.
This returns speed back to eo brining the overhead in my tests of
lookup for the elm genlist autobounce test in elementary from about
5-7% down to 2.5-2.6%. A steep drop.
This does not mean everything is perfect. Still to do are:
1. Tests in the test suite
2. Some API's to help for sending objects from thread to thread
3. Make the eo call cache TLS data to make it also safe
4. Look at other locks in eo and probably move them to TLS data
5. Make eo resolve and call wrappers that call the real method func do
recursive mutex wrapping of the given object IF it is a shared object
to provide threadsafety transparently for shared objects (but adding
some overhead as a result)
6. Test test est, and that is why this commit is going in now for wider
testing
7. Decide how to make this work with sending IPC (between threads)
8. Deciding what makes an object sendable (a sendable property in base?)
9. Deciding what makes an object shareable (a sharable property in base?)
I knew Windows doesn't allow statically initialising pointers in the
global namespace, I had no idea it also applies to functions. That's
quite annoying.
Thanks to Cedric for reporting.
It has been discussed on the ML (thread: "[RFC] rename efl_self") and
IRC, and has been decided we should rename it to this in order to avoid
confusion with the already established meaning of self which is very
similar to what we were using it for, but didn't have complete overlap.
Kudos to Marcel Hollerbach for initiating the discussion and
fighting for it until he convinced a significant mass. :)
This commit breaks API, and depending on compiler potentially ABI.
@feature
As far as I remember, declaring structures and arrays in a cast is a GCC
extension. I'm not 100% sure I'm right, but I remember it was the case.
Regardless of whether it's an extension or not, this commit removes that
pattern and makes everything cleaner (and faster?).
This is another follow up to the investigations of T4227. As stated
there, in any PIE (a shared library is one), structures, even const ones
end up being written to because of dynamic relocation. This means that
using static const structures has actually lead to no savings, only
waste. Since we never really needed them, using them made things even
worse than just having a different API that doesn't save them.
Thus, this commit changes the way we set the functions. Instead of
passing a pre-populated struct, we now just have an initialiser function
where you set the functions. This on its own doesn't significantly reduce
the amount of dirty memory pages for a reason I have yet to uncover,
though I believe it's done as a misguided compiler optimisation.
However, this design is flexible enough so we can change to another one
that is quite ugly, but I have already tested and proven that does that.
This patch series doesn't include the better improvement (passing
everything on the stack as va_args) because the API was too ugly
for me to bear, and I would rather first make sure there is no way to
force the compiler to do the right thing here.
Unfortunately this commit gives up on useless stricter validation.
Before this commit we would make sure that we are only overriding
functions correctly defined in our hierarchy. With this one, we don't
anymore. This is not a big problem though because this is a check that
is also enforced by Eolian. So as long as you are using Eolian, you
should be fine.
Breaks API and ABI!
@feature
This improve speed of processing events in genlist scrolling benchmark by 30%
inside the efl_object_event_callback_call code. Not a really big deal as it
goes from 0.9% to 0.6% of the total time spend. Welcome to micro optimization.
Cedric BAIL
Xavi Artigas
Daniel Kolesa
Daniel Kolesa
junsu choi
Lauro Moura
Cedric BAIL
Carsten Haitzler
Jean Guyomarc'h
Vincent Torri
Jean-Philippe Andre
Andy Williams
Marcel Hollerbach
Marcel Hollerbach
Gustavo Sverzut Barbieri
Guilherme Iscaro
Daniel Zaoui
Stefan Schmidt
Larry Jr
Tom Hacohen
Bruno Dilly
Felipe Magno de Almeida