just fyi. one solution is to just back out the "new software map rendering code" and go back to the old one for now. it's a "nuclear option" but it'd fix it. i'd rather not though and have @Hermet look at it.

no- this happens on 64bit too. the new map rendering code reads out-of-bounds. it miscalculates coordinates and pointer addresses. i've seen it fall over pretty badly when i tested the old screen setup dialog in e where you could rotate the monitor in the gui... :) lots of cases of large amounts of garbage pixels.

@Hermet ping ^^^^

oh wait... to be non-obvious you have to use requires not extends... this is kind of weird... why?

btw... this is horribly broken. to the point it's a showstopper.

a70808fb9643e95659582aced54e09555252afe7 + e6d9ea7539418ea2f898853c5f3655d3417153f7

quick hack that solves things... but not nice big-picture-wise... :(

I think @cedric did the mempool stuff. My original code would have just malloced everything. But I do know why it creates mempools per collection... So to free everything it just frees the whole mempool and not each item one by one, making the "free it" cost lower. This is kind of a work-around to eet originally not supporting arrays for encoding so everything was lists. This allows us to collect everything into one region of memory for this implicitly via the mempool (because mempools are the same-sized items, a bit like an array). As I mentioned before. I never expected out edj files to become so incredibly huge. I expected them to maybe have a few dozen part collections (group {}) or 100 at most. We've ended up at like 10-20x my "at most" expectation now by default. As I mentioned before... I'd do things differently if I got to re-do it but not even decoding but doing everything mmaped live from the file. for the directory entry of Edje_Part_Collection_Directory_Entry's I'd do something like:

hey @smohanty - keep things from getting personal. we DO have guidelines on how to behave: https://www.enlightenment.org/contact . You're not joking here and it's definitely crossing a line.

solved with 1106cf9db45e45a719fd26b2b5fdcc3c568a34c9 and 4bdb0212a2831087b5031c266c3ab44fdd85928a allowing you to set magnifier and desktop style entry mode in elm config gui

that's what i see - it goes up a dir to where the mount points will appear .... :) so we're on the same page then. :)

i've tried a few combinations of the options and i can't see a new window appear. i do see an existing window that points to the base mount point go up a parent, and others that point further in disappear with error dialogs. we could handle that a bit more consistently i guess... but... no new window. :( both eject and unmount -> same story. unless you change settings efm will not even mount until you open the dir in an efm window. it'll auto unmount when you close the window. it's intended to be this way to minimize filesystem dirtying until you actually need/use it (opening the window == using it). there is an option to do the "always mount anyway" but that exposes you to making filesystems dirty... so i don't know how to see what you're seeing :)

I have.... never seen that... ever. I am not even sure how that can happen? I unmount here and efm just goes back a dir if its in the root of the mountpoint or if its deeper it ends up closing the window(s) with these dirs with error dialogs. i dont see a NEW efm dir appear.

oh the orange blinker == scan, blue == visible.

that's up to bluez. it'll stop blinking when it stops scanning :)

can you try again after my commits that fixed a bunch of things that could have led to heap issues? once something is messing the heap (or even stack) up... it's kind of unreliable as to what else it may damage along the way.

I'm not that crash hot on Efl.Text.Annotation.Factory. Certainly as a name... Wouldn't Efl.Text.Range be better and as part of the constructor/construction of the range you have to pass 2 cursors? the question now would be - does the range keep tracking the cursors or is it fixed and the cursors are just used as markers for begin/end when u construct or set/change them later? so more:

just fyi. i build on aarch64, armv7 and x86-64 regularly (like multiple times a week on all and daily on aarch64 and x86-64) so if there is a break - i do not see it. it'd maybe be some special cflags or environment that induces the break vs what i build on/under.

just as a slightly more generic point... this is what eolian_gen was meant to be for. it's job would be to appropriately MAP the efl api to the native language. For example perhaps camelcase functions if that's what that language ecosystem prefers. it's job should also be to specifically deal with these issues rather than them leak into our .eo files themselves. rename classes or types as appropriate in the tool... then it also enforces a consistent naming for such situations too which is too.

Updated: We always use EINA_MAGIC , even in tizen people are scared to turn of EINA_MAGIC_DEBUG , so List Node Data size = 5 Pointer = 20/40 byte

I tried array/inlist for clippers and it was way worse, because of the access pattern.

If you ask me do i want to use a container which can only store a 4/8 Byte Data (pointer to data) for that it keeps 16/32 Byte of Book Keeping . I will not even look at it. (let alone how bad/good to access that 4/8 byte of data). If we just assume that there is no problem and bigger problem is somewhere else .. we are just ignoring the problem that's all.

well inlist always is part of much larger data structs ... so the inlist header inside a much larger one makes little difference so arrays will be just as cache-missy as a linked list as no single object item is less than a cacheline. ... they are all big structs. so let's skip that. that's the real world usage pretty much.

i see no code to free the hash when edf is freed... :) also yes - doesn't handle building the hash if stl->name is null properly :) in theory the incoming edj file could be malformed with null style names... so handle the case.

@bu5hm4n that's the idea of blist indeed. it's after a lot of thought on what eina list is bad at. it makes some compromises because it has to, but in return for other benefits. it's a "use in cases where it'd really help" cases. So trivially short lists -> not much help. Lists we very very very rarely walk -> not much help. Impossible for anything that keeps Eina_List * nodes middle-of-list and expects them to be "constant" until member removed. It doesn't solve inlist style use cases which imho are mostly for very big objects where arrays would not help and just hurt.

cool. i saw those :) let's call this done for now.

we very rarely need to store something that simple in a list... but i get your point. most of the time it's a fair bit more than that. unless you can show me the many uses of such tiny data structs (that are either filled with lots of data - thus wasteful or are walked really often - thus getting cache misses) ?

ok. well still - callbacks use a lot of memory too... :) i don't have much to say about vtable as i've never looked at it at all... so i'll leave that alone for now, but callbacks can be optimized a bit i think. it won't need a change in design other than looking at the events we have and maybe merging some or adding merged ones where valuable?

no one was interested. i've been meaning to drop this into eina and begin using it internally whenever possible. a slow move over to it would help.... a lot. it's designed to help with locality by having blocks be a multiple of contiguous cachelines. it actually will save memory on anything that is not a super-short list. it still looks like eina list in that it stores pointers to stuff (inlist is a different beast). i built it as a fairly easy move from eina list to blist... just read the patch review. it's intended as super-early "lets throw ideas around" for this to be a viable replacement for eina list in almost all cases. as it hides the implementation it can even just drop down to a single array internally if the data never changes and is just appended to most of the time. it could under-allocate blocks for super-short lists. there are openings for lots of optimizations it can do to be even better in corner-cases. we don't have to do all of them day 1. the first step is agreeing on the api & design being good. the implementation leaks out into design somewhat but not much. the only thing this can't do that a list can is keep a handle to a specific member of a list (an eina list node) and know that handle will be valid until that member is deleted/removed. it can't do that bit. all other uses if eina list are fair game. i also designed it to be less error prone so no list = func(list, ...); just func(&list, ...);

by bookkeeping you mean things like callbacks? because that is what was selected, but the vtable stuff was what was expanded...

yeah. actually found bug #2 in that patch. i still have one of my unlocked funcs still lock. forgot to remove them... now down to .... 28 locks to start elm test. so... update. locally with an updated patch... 615604 -> 28 lock+unlock cycles. i think... that will be good enough eh? :) even if a read lock is 3x as expensive... we do it 0.004% as much as before, and still get the write contention improvements. :) i call this a win.

cool. so i guessed what you wanted. btw that patch has a small bug in it. find it :) (i already have and fixed it locally). it won't affect running things and testing performance though.

oh yeah... env vars may in theory change between tests.

btw... that should actually be faster than the original spinlock before rwlock as it's even less lock+unlocks. as it's a rwlock multiple readers will not block each-other unlike spinlocks too. only a writer will end up blocking others and that path i have left as-is.

so do you mean something like: P319

nah - just a performance thing and it's not a huge one... it's only in some code paths. so not showstopper

i thought my git commit log explained that - it sped things up when there was contention ? can you provide much more detailed benchmarks and tools to show all the cases? like simple usage, more complex usage in single threads, multiple threads (a few of them, many of them) etc. ?

1. i moved to rwlocks because iw as profiling .. i think it may have been edje_cc writing out and it was like really bad with lots of threads using 100% cpu as they sat on spinlocks while writing stuff out. i think that was the case from memory.

ok. have a null layout as default now... and the gui displays it nicer ... and x skips it as well as wayland if basic or null... works for me in both wl and x11.

ummm... this is using efl_* namespace but it is clearly a legacy api.... this imho is not good. the rest i see no major problems with, but... this should be named something other than efl_wl ...

The below i typed with a xkb layout i added with the basic variant here locally:

@tasn is right - from the point of view of a user - it's the same. even if c# and java couldn't do it then its a "c only feature" - they can CONSUME it and make use of it from what efl does in C.

hmmm ok. well ... there goes that idea/path

well some good news. i found that everything issue. fixed it. pushed fixes. :) we still have the original core issue though...

hey @Hermet -> i spotted junk rendering with mapped content he other day when playing with the default e theme and the old old old e randr config dialog (you have to check out e18 from git tag and build/run that e.g. in xephyr). when u rotate the screeen you get flashes of junk. i've seen at time other flickers of junk. something broke when you change the sw rendering of mapped content here. i already put in some guards for segv's i saw but .. there must be more issues.

so for efl there is no use of knowing if mman.h exists (HAVE_MMAN_H) as it always will. evil guarantees that. so we just need more

yaaaaaaaaaaaaaaaaaaaaaaaaargh!

can u try apply this patch to e btw to see if the issue goes away (with everything module enabled):

ok. you have gdb attached there where it aborts. specifically i'd love to for to frame 0 - i hope if you do bt in gdb it gives you the same backtrace as asan does for the invalid read of size 1. i.e.:

done.

you have to set the ASAN_OPTIONS to disable leak detection to move on... try that under gdb. but every there seemas to trigger something... try unload the everything module and see if your crash on startup continues (rebuild without asan) ? let me look a bit into that complaint in the meantime

this means someone is providing mmanh.h even on windows... the rest (osx,bsd, linux) have it for sure. android will too and ios, solaris... not sure who doesn't have it that we care about then... except windows and that seems to be there?

oh wait.. u still had the old cflags inherited there there.. not what i told u to set which would override them:

hmm... possibly. let's see

the build just stops? you add the export ASAN_OPTIONS="detect_leaks=0" in the build() function of the PKGBUILD files of efl-git and enlightenment-git at the top of those functions? you might also add the export CFLAGD+LDFLAGS lines too there...

you need to have the ASAN_OPTIONS part of the build. you may have to set it in the PKGBUILD...

ok. new tack. ASAN. this will make efl+e a bit bloaty and slow, but nowhere near what valgrind does:

well with nothing that means it's not being triggered... so your latest tells me that the only path that could lead to an invalid ptr ... maybe... is not being triggered. so...

@vtorri - i can't seem to confirm minw32 has mprotect ... and evil doesn't. so are you saying that they are functionally equivalent (VirtualProtect and mprotect) and so evil could implement an mprotect on windows?

hmmm ok. can you be more special case. set a break for the case EVAS_COLORSPACE_AGRY88: where the if there is triggered.

ok. so normalize is being called. that gives me something to look at. perhaps we free cs.data and don't fix up image.data at the same time? let me look a bit.

does mprotect work on windows? mprotect is the newer of those. the rest are old (unix/posix-wise) with the exception of mremap which is linux-only.

i had a look over the evas image back end that deals with image data. every path i see that will free/unmap the image data also replaces the image data ptr with NULL ... or in 1 case it replaces it with new data (the cs.data). i was going to suggest adding some ERR() debug macros that will give a print of the image ptr value and a bt of where it is freed/unmapped but ... looking at it it's all seemingly ok. that pixel data ptr should be null... or it's a valid move to cd.data with normalize.

oh wait... never mind... that's what we had to begin with... shit. ummm... bugger... hmmm

well... try just plain gdb then... run e under gdb instead of valgrind:

it comes up with both screens working when under valgrind? just a bit slow... but works?

what @cedric says is right. filters address 80%+ of the needs. they probably should be fleshed out, improved and made more efficient in both GL and software as well as expanded in ways that allow them to fill "need this" gaps. well documented, tested and demo'd too.

Oh, so this allows Enlightenment to run at full speed on my main machine...that's pretty cool, raster! Why is that, though?

hmmm. well it may be firefox needs to chase this up in some way... but i am pretty sure efm/e are doing the right thing... :) i'd love to know if they are not though.

@cedric - ok. fair enough. :)

you need to start an xserver manually. so somewhere as root (tty or ssh session - i recommend ssh'ing in from another system for comfort and a later copy & paste):

ok. so intel gfx... broken drm is quite normal ... had to work around structs not matching the memory layouts defined in the drm headers - figured that out years ago :)