Sometimes display ref count is not zero after wl_display_dispatch_pending.
For example, wl_data_source_listener's callback is called by wl_display_dispatch_pending.
Display ref count is not zero but display is cleaned up, it makes double free corruption.
Reviewed-by: Christopher Michael <devilhorns@comcast.net>
Differential Revision: https://phab.enlightenment.org/D12109
in theory signal handlers could kick in after fork and before exec...
so block them until we're exec'd or exited so they don't change any
program state.
this won't happen as the setup should not have the # of fd's found in
2st pass and 2nd pass for a dirfd change as nothing should interfere.
comment to that effect and add a paranoid change num_closes to the
number found
post flush doesnt cleanr evas->rendering until after it calls post
flush callbacks. any post flush callback that neexts so access data
and block waiting for an async render tyo be done thus blocks forever.
this adds a 0.2 sec timeout in case so we at last march on with
hiccups instead of totally stalling AND clears evas->rendering before
calling the callbacks.
@fix
while it requires an extra wakeup from vsync thread -> e and this adds
a bit of jitter, it's mroe reliable in the face of "missed a frame"
timings and doesnt degrade as badly.
At least on Windows (didn't have the time to test on Linux yet),
running tests, even if they passed, there would be an Eina error on logs
pointing that a temporary file wasn't closed:
```
ERR:eina_file ../src/lib/eina/eina_file_common.c:1137 eina_file_shutdown() File [C:/Users/joao_/AppData/Local/Temp/aaaa_file_test_EBpVea] still open 1 times !
```
In the end, it was the `eina_file_test_unlink` that would create a temporary
file but never close it, being caught only by `eina_shutdown()`.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Reviewed-by: Vincent Torri <vincent.torri@gmail.com>
Differential Revision: https://phab.enlightenment.org/D12062
Reviewed-by: João Paulo Taylor Ienczak Zanette <joao.tiz@expertisesolutions.com.br>
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D12108
In some systems (such as Windows), OpenSSL raises an error about "No Applink"
(see ["I've compiled a program under Windows and it crashes: why?" in OpenSSL
FAQ](https://www.openssl.org/docs/faq.html#PROG3)). Including only
openssl/applink.c didn't work, so the solution was to replace `FILE*`
interfaces with OpenSSL's BIO API which also contains file operations.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D12103
Summary: Resolve rendering e vowel (0x1031) with Myanmar(Burmese) with zero width non joiner (0x200C)
Test Plan: ninja test
Reviewers: woohyun, bowonryu
Reviewed By: bowonryu
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12102
Summary:
If shadow format changed using style_apply , the event EFL_CANVAS_TEXTBLOCK_EVENT_CHANGED will not be fired.
also added tests for it.
Reviewers: ali.alzyod, woohyun
Reviewed By: ali.alzyod
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11078
I found wrong API group name in elm_win and elm_glview and fixed them.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D12075
if this is set to 0 the next iteration in the upper frame event would
decrement the 0 again leading to a overflow making the iteration and
callback array overflow.
Long story short: set ifx to 1 to prevent overflow, test added.
fixes T8787
Differential Revision: https://phab.enlightenment.org/D12101
If we don't have a buffer here you CAN lose the race when scrolling.
As there is a check later in the flow, we can just use a padding
of 64 instead of checking the range. This ensures that scrolling is
smooth and content is always rendered throughout an aggressive
scroll.