Test Plan: run on XP
Reviewers: jpeg, cedric, ajwillia.ms
Reviewed By: ajwillia.ms
Subscribers: ajwillia.ms
Differential Revision: https://phab.enlightenment.org/D5245
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 makes sure that the call to madvise is safe. On Linux it's not too
much of an issue as checks are made inside madvise, and the worst that
can happen is an error is returned (EINVAL). Not great.
But if MAP_POPULATE is not present, as is the case on *BSD, then the
internal function _eina_file_map_populate() is used for the populate
rule. In that case actual data is read and we should make sure not to
trigger a segfault or bus error.
Also, this makes sure that in case of HugeTLB we actually populate all
pages, rather than one page out of 8 (we were jumping by 16Mb instead of
2Mb).
Note: Can we get the size of a HugeTLB at runtime? We're assuming 2Mb
which might very well not be the case!
See: https://wiki.debian.org/Hugepages
Tested by disabling MAP_POPULATE and observing crashes :)
@fix
Summary:
The code in eina_debug.c requires the eina_swapX() functions on big endian platforms, so include the required header.
Test Plan: Do build on big endian platform like ppc64 or s390x.
Subscribers: kubu, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5158
Well... that's just embarassing... semaphore_destroy() actually takes
the mach task as its first parameter, not the second. This core
amazingly worked very fine on macOS earlier than Sierra.
Fixes T5245
This is a helper that creates a promise, then a future and immediately
resolves the promise, this will let the future be dispatched as usual,
from a clean main loop context.
restrict mapping /dev/zero to only eina files having a sigbus
reported. the mmap was before all our file access used eina_file i
think thus the raw mmap of it. now walk all eina files and find the
candidate and only then if it exists flag is as having a faulty i/o
backing and map the zerto pages then return, otherwise call abort.
more restricted mapping and perhaps a fix for not trapping non-efl
issues.
@fix
since we have a sigbusd handler that flags an eina file with io errors
it has to walk the file cache and every file... taking locks. if those
locks were taking already in the current thread the sighandler was
called in... we'd deadlock. since this basicallly never happens (when
do we see i/o errors really? not much)... we never saw this as it'd
also reauire this race condition to happen too. but it is a problem
waiting to happen. this fixes that by moving to recrusive locks.
@fix
These helpers are similar to eina_value_X_new(), however do not
allocate the Eina_Value, rather return it.
These are useful when the value struct storage was already there but
needs to be initialized in a single line, like as stack variables or
when returning a value.
these utilities are very useful, but names became too long. Since they
do not conflict with anything else, shorten them.
Since they were available before as inline function, provide a macro
to rename them for old source that's compiled against newer library.
EINA_VALUE_EMPTY is basically a zeroed Eina_Value, handy for declaring
and returning.
To cope with the rest of efl, free/del/flush on NULL shouldn't
complain, so flusing an empty value should be quiet.
When a virtualized file is created the file->global_map will not
point to a mmapped region, thus it's not safe to use munmap() during
the file cleanup. Only use munmap() if the file is backed by a FD.
Fixes: T5234.
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>