Can be worked around for now by enabling "Use system title bar and borders" and then restarting Brave.

This is a chrome/chromium bug:
https://github.com/brave/brave-browser/issues/18895
https://github.com/brave/brave-browser/issues/18906

I forgot to mention, while I have the same issue, the main difference is that efreet does stop after 1m28s (according to bpytop) with my 5900X.

In T8962#156054, @raster wrote:

You would need to trace the process to find what it's doing. strace, gdb + get backtraces. if i saw this happening i'd be debugging it. i don't see it happening. the only things i can think if might be it's a thread deadlock (something stuck on a spinlock) or its some loop - and a loop here i might imagine is in your filesystem - e.g. symlinks that create a loop. so e.g. a symlink that goes back to a parent directory that is in a child directory.

Conditions: enlightenment efl git, Arch system, Arch Aur package
Each time i launch enlightenment X session, 'efreet_icon_cache_create' eats 100% cpu and lot of disk ressource for many minutes. It never ends, even after enlightenment exit, i have to kill process. Same issue with Wayland.
Process:
/usr/lib/efreet/v-1.25/efreet_icon_cache_create -d /usr/share/enlightenment/data/icons etc..................

Something else I just noticed.

In T8942#155766, @raster wrote:

i dont see this and my screensaver kicks in a lot.... same as your git efl/e - i haven't seen this. default theme too...

Alright, those two commits solve that problem.

In T8905#155571, @raster wrote:

that is totally bizarre. when scren is on it does the same even when idle? like 60-100% cpu? can you run perf top again and specificall speed up its sampling rates and look at what it says when e's cpu spikes?

perf top -p `pidof enlightenment` -F 50000 -z -d 1

(man perf-top - 50000 might be too high a sample rate - may have to lower it).

i wonder if this is an nvidia problem?I don't see how it can be as e suspends rendering... ? do you have the option of switching to intel gfx entirely? do you use nvidia or nouveau? perhaps perf is not picking up the cpu usage in the nvidia blob?

In T8905#155568, @raster wrote:

7f02c5709298cfe915fe1dc0436d74932a11f6f1 + f98a8e82d2fb4b9a5385dd0403b94e47587fe42a

these above now freeze the clock entirely so it'll be totally idle (other bits of e may wake up to do things but not the clock now - not to tick over seconds/minutes etc.)

still - e should not be using so much cpu just ticking over. as i said - even on an old old laptop (i5-4200U CPU @ 1.60GHz - when blanked e forces it down to 800mhz and doesn't allow it to clock-up so e will use more % cpu than if at top clock speeds because the cpu is running slower to save power) ... 0.1 -> 0.2% cpu according to bpytop (use the same tool as you to stay consistent). i am baffled as to why you see so much cpu % being used. also memory used is massively more. 332m. so if your system is idle - no apps running (rendering stuff) ... what does bpytop say? not with the above commits - right now before you update?. my changes above will make the clock stop ticking entirely while the screen is off.

In T8905#155558, @raster wrote:

well well... but how is it using so much cpu? well ok - I can think of something - when a digit flips the clock in the old dark theme uses an animation that makes it flicker in like broken fluorescent tube.

perhaps disable seconds display - or.. update to git master as now flat theme has dropped and it does no animation for clock digit flips.

In T8905#155554, @raster wrote:

unload all modules, then load 1 at a time? at least that will tell us if it's related to a module or not and if so, which one. another you can do is update your build to current git master... :)

In T8905#155544, @abyomi0 wrote:

Hmm. Maybe I ought to wipe out my config...

Hmm. Maybe I ought to wipe out my config...

In T8905#155541, @raster wrote:

hmm well something is seemingly animating and using embryo script along the way... what is animating will maybe indicate what is going on... ?

In T8905#155533, @raster wrote:

well nothing special there - something from theme is running. try this: remove the cpufreq gadget from your shelf?

After E blanks the screen.

Ah, okay.

Checking via bpytop.
It looks like this...

You wouldn't happen to have Enable Custom Fonts enabled, would you?

Looks like something is off for me, too.

I noticed the same thing.

In T8159#140711, @raster wrote:

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.

just fyi... i saved perfect shots in my desktop dir 3 times in a row - no crash and i have asan on 24x7 on my desktop. so... i'm not seeing it.

Whelp. Even without optimization, Frame 3 is a problem.

this was happening before, but usually, it'd crash with this on the screen.

In T8021#139778, @raster wrote:

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

can i ask a question... do you have under settings -> compositor -> advanced -> rendering -> ... is texture from pixmap enabled or disabled?

the elusive hesienbug.

Eanimator crash on startup.

In T8021#139523, @raster wrote:

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

export CFLAGS="$CFLAGS -fvisibility=hidden -g3 -O0 -fsanitize=address -fno-omit-frame-pointer"
export CFLAGS="$CFLAGS -g3 -O0 -fsanitize=address -fno-omit-frame-pointer"
export LDFLAGS="-lasan"
export ASAN_OPTIONS="detect_leaks=0"

notice this will add on to the cflags.. not totally reset them... you do NOT want any cflags inherited from makepkg global config etc. so you want:

export CFLAGS="-g3 -O0 -fsanitize=address -fno-omit-frame-pointer"
unset CXXFLAGS
unset CPPFLAGS
export LDFLAGS="-lasan"
export ASAN_OPTIONS="detect_leaks=0"

after trying myself i notice makepkg sets CPPFLAGS too and explicitly sets CXXFLAGS so you have to unset them... but... when i try and use makepkg i also get the hang... it sets up something else in some way to cause the hang that's different to my normal build. the only configure option that's different is i disable physics. yup. that solves it. so let's do this in full. in the mapkepkg for both efl-git and enlightenment-git do:

1. the options near the top = change it from options=('debug') to options=('!strip')
2. stick this blob of environment variable fixing at the top of build(): ` export CFLAGS="-g3 -O0 -fsanitize=address -fno-omit-frame-pointer" unset CXXFLAGS unset CPPFLAGS unset MAKEFLAGS unset CHOST unset COMMAND_MODE unset TEXTDOMAINDIR unset TEXTDOMAIN unset SOURCE_DATE_EPOCH export LDFLAGS="-lasan" export ASAN_OPTIONS="detect_leaks=0" ` do not keep any export lines after it or have any before it - remove them. you want these environment variables set exactly to what i have there or removed from the environment entirely.
3. in the meson options where it passes -Dxxx=yyy you want to add this like: ` -Dphysics=false \ `
   
   before the . build somewhere. i'd rather you be able to compile so you can do updates and try multiple times... for me to build i have to remove my existing /usr/local efl install out of the way that actually is running my desktop while i compile, BUT https://download.enlightenment.org/~raster/ has the 2 pkgs i built just now with asan and debug enabled. the problem is they will depend on my src tree for gdb debug etc. which will make them useless to you for that. so first try the above to get it to build...

I had an idea.

In T8021#139473, @raster wrote:

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...

I tried rebuilding efl-git (and efl from source) by exporting the those flags, but it just stops building partway through. It doesn't appear to crash, it just stops.

Unable to rebuild the EFL due to detected memory leaks.

I ran that, but the output I got doesn't appear to be anything useful whatsoever.

In T8021#139432, @raster wrote:

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.

sorry about this. it's kind of "remote debugging" where now i have to ask you to do the things i would (slowly with long round-trips).

In T8021#139428, @raster wrote:

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.

if you run e under gdb, before starts running... can y set a breakpoint for evas_common_image_colorspace_normalize ? so:

gdb enlightenment
br evas_common_image_colorspace_normalize
r

br == set breakpoint
r == run

do u get the breakpoint triggered. if so, can you step through and see what im->cs.data and im->image.data are.... then continue running.... (cont) then if/when it crashes later is that the image.data ptr later on? is the breakpoint hit at all?

we're now into deep debugging land. :(

the only other option i can think of is that memory for the image struct is being scribbled over with junk thus producing a bad data ptr. i could start adding checksums to the struct etc. to try detect something going wrong.... but it won't find the source of the issue - just detect it went wrong (which gdb/os kernel is doing already - thus the crash).

In T8021#139396, @raster wrote:

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

In T8021#139387, @abyomi0 wrote:

In T8021#139386, @raster wrote:

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

Oh.

that should not run at full speed.. valgrind will say to paste some trace command into gdb then continue running... did you paste that in? that will have gdb remotely attach to a special gdb debug port in valgrind that allows it to see the valgrind interpreted process...

ERR<769>:e ../src/bin/e_comp_x.c:5670 _e_comp_x_setup() Another compositor is already running on your display server.
<<<< Enlightenment Error >>>>
Enlightenment cannot create a compositor.

E: Begin Shutdown Procedure!

hmm no - e didn't even start there. another wm/compositor was running... was this the raw empty xserver you ran manually? did you ensure no other Xserver is running at that time?

That was the raw/empty X Server. I disabled sddm before starting the ssh sessions.

I can retry this in a few minutes.

In T8021#139386, @raster wrote:

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

In T8066#138907, @raster wrote:

then i don't know what firefox is doing. it's not using the xdg ~/.config/mimeapps.list which is now these days the modern place to store default applications. e will write them there. the old one is ~/.local/share/applications/defaults.list but that changed quite a while back. xdg-open is doing the right thing. efm it doing the right thing. e stores things in the new location. it will at some point even upgrade your config and copy it over from the old to the new... so i don't know... you seem to have a firefox problem i think. do you have an old defaults.list file? does it have different content? is firefox not even reading these files at all and ONLY using the desktop database and choosing something for you?

In T8021#139363, @raster wrote:

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):

X -ac :0

then in another tty or ssh login session:

export DISPLAY=:0
export E_START=1
valgrind --main-stacksize=4096 --vgdb-error=0 --tool=memcheck \
  --num-callers=80 --show-reachable=no --read-var-info=yes \
  --leak-check=yes --leak-resolution=high --undef-value-errors=yes \
  --track-origins=yes enlightenment

(the valgrind command above is what i use personally so it's got a lot of options turned on - but i have an alias in my shell for it so i don't have to remember it all) then in ANOTHER ssh or tty session run:

gdb enlightenment

then copy & paste in the trace attach line valgrind tells you to and use the cont or c command in gdb to continue running in gdb until the error pops up and gdb breaks and gives you a backtrace and valgrind outputs where it thinks the problem is. some problems can be ignored, so you can just "continue" like "branch depends on uninitialized memory" ones. others like invalid access (to invalid or freed memory) are going to be the fatal ones. you want a backtrace from those and printing of local variables and structs etc.

In T8021#139348, @raster wrote:

you're going to have to try it with a raw xserver then and valrind it from another box... (ssh in)

In T8021#138864, @raster wrote:

yup. :) That's why we wrote it :)

In T8066#138881, @raster wrote:

let me guess... firefox uses xdg-open. try use xdg-open on the file?

In T8066#138865, @raster wrote:

when u want to open a file in EFM ... then right click and "open with... other application" and select
whatever you used last is remembered and efm will keep using that until u open it with something else. default apps under the pdf mimetype should be showing what efm will use... which is what enlightenment_open will use... but i don't know how its being opened - you are saying e opens it so i assume efm in e... (which is part of e)

In T8021#138570, @raster wrote:

ok. we're passing in a bad ptr for the pixel data... and then the nvidia driver is barfing at trying to access it, so our problem... but why? next port of call - valgrind i guess.

Did:

frame 12

print ((int *)pix)[(w * h) - 1]

Here's a more recent backtrace:

This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.

In T6197#103197, @raster wrote:

just an idea. can you, in e_auth.c in e's src in the e_auth_begin() function at the end of the file... replace exit() functions with _exit() (the extra _ at the front). this will prevent atexit handlers from being called. it may work around the driver issues above.

In T6197#103194, @raster wrote:

ok - that backtrace shows e hung inside nvidia's drivers. that's a hang there? the nvidia driver just has stalled (we have no idea what - we never will because it's binary and you'll have to ask nvidia to tell you).

I later recomplied Enlightenment without optimization, but the backtrace I got afterwards looks nothing like the one I uploaded. So the one here is the one with optimization.

In T6197#103113, @raster wrote:

all of them? enlightenment itself will do this.... but all of them doing this?

In T6197#102945, @raster wrote:

thats a lot of enlightenment child processes... a lot... how? .... can you gdb attach to those (gdb enlightenment PID) and get bt's from those?