Summary:
alloca force the memory to be accessible for the entire duration of the
scope of the function it is called from. This will garantee that the
memory pointer are not recycled under our feet before we check them.
T8020
Reviewers: zmike
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8020
Differential Revision: https://phab.enlightenment.org/D9127
so i think there was also another bug as i saw this again now. this
should hopefully plug the signal/mtach memory bugs now by removing
and adding back to hash as the hash key relies on the memory addresses
of signal/src in the matches array which change on realloc. a bit
brute-forceey but... better than crashes.
@fix
also a general cleanup of the code to make it easier to follow/read as
this seems to have problems but i cant reproduce them enough to find
them. i noted a realloc would have invalidated pre-stored pattern
ptrs that would cause segv's for sure. also code paths where reallocs may
fail and not handling those cases at all etc.
@fix
in 1 situation at least we delete the eina file (close it) but keep
the ptr around (during destruction) which could cause issues with
callbaks and events on del and so on.... which may lead to multiple
closes where only one should happen ... which would explain my invalid
eina file ref problems i'm seeing. i carefully matched eina file
handle stores/opens/dups to closes in edje/evas and they seemed to all
match up so this audit with comments and fixes seems to have plugged
that now.
@fix
so if you use sw and gl enignes in a process and have color font
glyphs.. *BOOM* because the color glyph code used ext dat that was
intended for engines to extend with a gotcha of "only 1 engine can
extend this"... commented already.
so this unfortunately adds an extra ptr per glyph to store color data
explicitly. but now it both renders right and doesn't crash. we still
have a limit of 1 engine alone can extend glyphs with ext_dat though.
@fix
in the case pipes fail to create we'll close the wrong ones... this
fixes that. it also happens because i didn't use names consistently.
now it does so it's easier to keep right.
thanks coverity.
fix CID 1396994
also.. note the badness of the code design mixing a global singleton
with a "per struct" set of data like fd handlers for the same devices
initted only once but... anyway. it's messy.
so even if shm was an allowed mode/flag, we never fell back to shm if
dmabufs were not possible (/dev/dri/renderD128 didn't exist or wansn't
open-able). that's decidedly a bad thing to do.
@fix
i saw a segv on freeing em->msg as it was a junk ptr... i dont know
for sure it msg was properly initted but as em is recycled from trash
be sure and zero it when digging out of trash because em->msg was not
a valid ptr (and i wasnt using valgrind at the time to know for sure
and cant find this with valgrind now).
@fix
during cursor free a move cb seems to add another job again after it
wss already deleted during the free process, so just clear the job
really late instead. valgrind found this one
@fix
so i've been wondering what is going on for a few days... and i've
figured it out finally... my mouse seems ot like to generate 1000
events per second. not your usual 100 or 200. it only happened on this
one machine so i was wondering what on earth was up. this machine was
different in other ways like an arm cpu, differing gpu (rx550),
different distro and so on. this is creating a storm of motion events..
and this is causing all sorts of overhead in just trying to deal with
them all like generate more internal events, emit signals for every
one of them and so on. there is no attempt to play catch-up or
anything - just build up a bigger and bigger queue of them to deal
with. this is NOT GOOD. this restores our old commented out event
skipper that got commented out during some xcb work actually -
not on its own. it was a huge xcb patch that commented it out.
this restores it and makes it a little cleaner with a bool and now the
perf issues i was seeing are gone. this is such a major performance
fix that this deserves a backport.
@fix @optimize
i missed 1 rare case where we start in the middle of the list and have
to walk to the end. testing didnt show it up. fix. this fixes up that
case in b5ed76ba9f
to walk inreverse we need to jump to last first then walk backwards...
what we were doing is calling eina_inlist_last() which is defined to
walk rather than that using list->last ... this totally got rid of
_evas_event_object_list_raw_in_get() from my perf list ... and i was
wondering how it got there to start with.
this is such an obvious optimization...
more optimizations for edje messages to avoid excess alloc and frees
if we have some trash around... since messages already have list
nodes, re-use the main list node for storing trash and not eina trash
as this avoids extra allocs for trash nodes.
so to process a single obj we added a lot of mesgs to the message
queueue only then to wak most and SKIP most msgs again and again -
when this adds up to 1000's of messages and 10k+ then literally moving
a window in e hangs for multiple seconds and we walk such lists in On2
like complexity. this gets it down to O(1) along with some other minor
optimizations of not adding to tmp list only then to add them to the
nex queue/list.
there is more i can optimize here as well now we track messages for an
edje in th edje. that's next.
using regular lists means we double our indirect ptr jumps and
fragment ram more - this is step one in improving performance of
message handling in some nasty corner cases i have found. first this
so it can be identified as an issue on its own if it is one. i've
tested it and it seems ok. so this si stage 1.
we don't force buffers to flush in wl... this will fix that and force
them removing an ugly hang for possibly seconds in cnp from client to
client or even within a client.
remember:
flush your mush.
@fix
it seems with those two actions here in the commit, do use id in a
different way the other actions do. This is commit protects against
this.
Differential Revision: https://phab.enlightenment.org/D9078
Until the cause of these issues can be found exit and
print error messages to console. edje_cc is currently
not reliable on OpenBSD. Until then anyone wanting to
use EFL on this platform will need pre-compiled .edj
files.
Differential Revision: https://phab.enlightenment.org/D9077
Summary: Avoid unnecessary operations on unrealized item when item field update is called
Test Plan: Call item_field_update on an unrealized item
Reviewers: cedric, raster, SanghyeonLee
Reviewed By: SanghyeonLee
Subscribers: #reviewers, rajeev.jnnce, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9019
Summary:
some widgets do not create a minimum size for themselves, resulting in
a 0x0 layout which can affect tests that rely on object visibility to
succeed without errors
Depends on D9007
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9008
Summary:
we want to make it clear in our tests where it is intended that warnings
and errors may occur
Depends on D9005
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9006
Summary:
this isn't a perfect fix, but it's probably the best that can be done
given the current ecore-imf module api which calls the exit() module
function unconditionally during module cleanup even if the module was
never initialized
@fix
Depends on D9003
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9005
Summary:
this object does not exist if no image border is set
@fix
Depends on D9002
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9003
Summary:
adapter can be null if it was previously destroyed
@fix
Depends on D9001
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: bu5hm4n, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9002
Summary:
there is nothing to update here if the scroller has no content to update
@fix
Depends on D9000
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9001
Summary:
this ensures that all necessary objects exist in order to successfully
perform the zoom
@fix
Depends on D8999
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9000