if there is a error when settings API to the vtable, free the vtable
instead of leaking it.
CID 1422015
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11580
as coverity points out, _obj_is_override is already dereferencing
obj->opt so this was the wrong spot to check this.
CID 1422014
CID 1422013
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11579
otherwise we are allocating a 0 sized memory element, which is
pointless.
ASAN would report a 0 sized allocated but not freed element as a leak.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11577
sometimes there is the chance that we need to allocate memory depending
on the functions that are defined, not on the types that are available.
However, even if this should only happen in error cases and on mixins,
we should ensure that this is all correctly freed flagged.
Due to the correct flagging here, we are not copying the memory later on
in a wrong way.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11576
allocating 0 sized elements here is pointless.
This here was doing that, so ensure that we are only allocating vtable
nodes that have more than 0 function pointers.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11575
otherwise we would not free it in the next run over the vtable. Which
would result in a leak.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11574
the free methods here accidently took the top of the mro into account,
which is the class itself, which NULLed out the wrong classes.
After this, we are finally freeing the mixin vtables.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11573
we have initialized it, we should shutdown it.
This was we are not getting random vtable allocation leak reports in the
asan job anymore.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Chris Michael <cp.michael@samsung.com>
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11572
when handoverwriting function on a object, only existing API can be
overwritten, but not newer ones. Thats why its enough to pass the size
of the klass, and not the size of the globally defined classes.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11571
Summary:
the same as norender, but useful
Depends on D11581
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11582
Summary: this is a valid combination of parameters that should be handled
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11581
Summary:
In transit, event_callback is mainly used for delete callback.
transit uses evas_object_freeze_events_set to control the user's mouse events.
However, EVAS_CALLBACK_DEL was not called because of this.
The behavior of evas_object_freeze_event was changed. This patch was created to fix some issues.
Test Plan: N/A
Reviewers: Hermet, kimcinoo, herb
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11562
Use a full eina_log domain here for each executable. No need to have a
own half baked ex_printf version here for such things.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11558
We do not want to have EAPI from exactness exposed at this point without
any real user. I know of no application using the exactness library.
If we come to that point we can move things back into a lib, but for now
having the code shared between the various executables is all we need.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11545
Summary:
elm_transit freezes events by default for added objects.
We have to use elm_transit_event_enabled_set to use events.
Test Plan: N/A
Reviewers: Hermet, kimcinoo, herb
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11560
need to be clear here since we own these objects
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11500
this is valdating the previous commit.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11557
this here needs to pass the flag that gets set, not the flag that
results. This is important for the cases, where a subtree in a widget
tree keeps the flag. As this would leave the wrong counter.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11556
When `C` calls a function that return/has an out string and it was overwritten by `C#` inherit class the `C` portion
wasn't cleaning its copy. Now, when a `C` calls a `C#` delegate function, `Strings` that are `out` values or `return`
values use a new marshaler (specific to this case) that uses Eina short lived strings (`Eina_Slstr`) instead of
duplicating it with `strdup`, so at some point, the string passed to `C` is deleted.
To do so, a `direction_context` (a new `Context` at `generation_contexts.hh`) was created. It is only used when a C#
delegate is being called from C (so this context is only set in `function_definition.hh` and `property_definition.hh`,
where it is set to `native_to_manage` to indicate that it is a native call to a managed function).
When this `direction_context` is set and the `String` being marshaled is not marked with an `@move` tag and it is an
`out` or `return` value, the new `StringOutMarshaler` (implemented at `iwrapper.cs`) is used (instead of
`StringKeepOwnershipMarshaler`).
When marshaling a managed data to native this marshaler uses eina short lived string (`Eina_Slstr`) that will be
automatically deleted. This delete is bounded to "the loop of the current thread or until the clear function is called
explicitly" as said at `src/lib/eina/eina_slstr.h`.
Reviewed-by: Felipe Magno de Almeida <felipe@expertisesolutions.com.br>
Differential Revision: https://phab.enlightenment.org/D11434
Summary:
the internals of those two methods have been the same. Both setted the
internal numeric flag as either as 1 more or equal to the flag in the
parent object (depending on the internal state). Further details can be
found in the comment in code.
Depends on D11554
Reviewers: zmike
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11555
Summary:
eval all children is ending up in the complete discovery of the whole
subtree, which is unnessesary here, as we are already discovering the
whole subtree with the calls, these changes are in, so simple
evalulating this is enough.
Depends on D11551
Reviewers: zmike
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11554
Summary:
this fixes disabled set behaviour. This ensures that when setting
disabled twice, that unsetting it once does not break the overall state.
This never appeared in any real life example, because
elm_object_disabled_set is already checking for equalness. However, this
is not wanted here, because the simple setter can also be used to sync
the state with the parent, which appears to be helpfull.
Depends on D11550
Reviewers: zmike
Reviewed By: zmike
Subscribers: zmike, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11551
Summary:
when setting twice the same value, unsetting the same value would not
restore the same state in the tree again. With this commit, we ensure
this is working correctly.
Reviewers: zmike
Reviewed By: zmike
Subscribers: zmike, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11550
we want to check if the pointer is available, and not the value of the
pointer. This fixes some "Jump depends on uninitialized value" messages
from valgrind.
Revert "eo: redo vtable mro creation"
This reverts commit b05110609b.
Revert "eo: add a generic memory allocation tracking method"
This reverts commit 44071e3102.
Revert "eo: rework vtable allocation scheme"
This reverts commit 3bd16a46f1.
Revert "eo: do not allocate extension if deleting"
This reverts commit 64f7edc7fc.
This seems to breal vector rendering in lottie:
From: Hermet Park <hermetpark@gmail.com>
To: Enlightenment developer list <enlightenment-devel@lists.sourceforge.net>
Subject: Re: [E-devel] [EGIT] [core/efl] master 02/05: eo: rework
vtable allocation scheme
This patch occurs memory corruption, vector crashes :(
Here is a sample if you'd like to see it.
https://phab.enlightenment.org/F3858944
Previous vg didn't take care of cached buffers which were
allocated in it's lifetime because the cache buffers are managed
by its own cache buffer mgr, it has a limitation count of buffers also
buffers can be cleared when engine is shutdown.
This behavior is actually working properly but not well optimized
since it lost a chance to clear grown buffers.
Now vg do clear used buffers when object is invalidated.
Summary:
up to now we have created the vtable of a class by walking the mro from
the most upper element to the klass itself. To give a broader view, the
mro of a klass X that extends the class Y and implements A,B,C,D
The mro of X is then equal to [A,B,C,D] + the mro of Y. Which means, we
can simply copy over the vtables of Y, and start walking at D, which
will result in the same vtable.
The sideeffect of doing that is, that we do not allocate that much
memory anymore. Reason for this is quite simple:
For every mixin that is part of the mro, we are copying the vtable node,
to insert new API implemented by the mixin. However, the resulting new
vtable is every time the same. Which means, we could actaully copy them.
The same messurements as in the previous commits are taken:
malloc tracking:
new: 452128
old: 556656
Safeup: ~102 KB
pmap:
new: 542884K
old: 542168K
Safeup: ~716 KB
Depends on D11538
Reviewers: zmike, stefan_schmidt, tasn, raster, woohyun
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11539
Summary:
this is super usefull when checking memory allocations. Esp. when
checking out new memory allocation schemes.
Depends on D11535
Reviewers: zmike, stefan_schmidt, tasn, raster, woohyun
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11538
Summary:
with this commit a new way of allocating vtables arrived.
The old mechnism was to allocate a table big enough to carry *all*
functions at once, in order to not allocate that much memory for
functions that are not implemented on a specific klass, dichchains have
been used, which can be seens as a 2D matrix, where columns are only
allocated if min 1 entry needs to be written, this may have been a good
way to allocate back in the day when all this with eo started, however,
it showed to not pay off.
With this new way, we allocate a array of arrays. the first lvl array is
carrying enough slots, that *all* up to the time defined
interfaces/classes/abstracts/mixins can be implemented. The second lvl
array then has exactly the size of the defined APIs. The second lvl
array is obviously only allocated if needed.
When comparing the two methods, i messured two things, the usage based
on memory allocation for vtable-way-1 and vtable-way-2. Additionally, i
checked the overall memory usage of elementary_test using pmap. The
first messurement is a little bit more exact. The second messurement is
more biased, but captures the whole picture.
Memory allocation tracking:
vtable-way-1 - vtable-way-2 = 74680 Byte
Pmap memory tracking:
vtable-way1 - vtable-way-2 = 217088 Byte
The second messurement shows a bigger impact, likely because this is
also showing off all the sideeffects that we are taking place due to
fewer allocations.
Depends on D11524
Reviewers: zmike, tasn, stefan_schmidt, woohyun, cedric, raster
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11535
Summary:
->ext is getting freed during invalidate. If we unregister during
destruction (which is something that might happen) we should not
allocate the extension again.
Reviewers: woohyun, zmike, eagleeye
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11524
Add support for Text Interactive interface.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11486
As described in task T8617
when toggle editable mode for textbox, we will reserve user changes (instead of reload them again).
this issue is affected by D9502, I do not fully understand why do we need it, so I leave color loading as it is.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11404
when this lock is released, the evas may be immediately freed, leading to
invalid access in the log call
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11536
Christopher Michael
Marcel Hollerbach
Mike Blumenkrantz
Carsten Haitzler
Xavi Artigas
junsu choi
Stefan Schmidt
Lucas Cavalcante de Sousa
Hermet Park
Bartlomiej Grzelewski
Ali Alzyod