Ah, maybe I can run it through valgrind later, will see.

The top crashdump is the same place. It's deep inside the nvidia driver somewhere and no idea why. this certainly is not the notification bug thing you saw (I've been trying to reproduce it with asan on and find nothing here - e keeps running solidly day after day with notifications and i installed the same browser extension you did). but .. this is on amd - different gl library. as the gl library is just code that executes inside of the enlightenment process, a problem inside that library can cause just about any problem like memory corruption and crashes. it's not isolated in any way. asan doesn't find any issue because it isn't directly inside code executed by efl or e (as asan adds checking code into that to make sure it's doing things right). youre option now is to use valgrind - but it's slow. it interprets every instruction a process runs and does this checking for ever ything. it may not be able to provide details other than "some code inside libnvidia.so did X to memory Y" but perhaps that memory might be some memory efl passed into gl. if efl (evas gl engine in this case) was passing bad memory into drivers and then they accessed it - i would be seeing your bug too i imagine. my guess here is this memory is internal to nvidia's driver. you're down to valgrind now though.

I was able to reproduce the vt swithching crash after installing the asan versions. Switched back and forth a few times and noticed all windows were black when coming back, and the last couple of times I only got the cursor, and then it froze too. Copied the .e-crashdump file and appended the datetime, then tried switching back and saw the Guru meditation error, and recovery worked. After that I read the logfile and saw it mentioning to use eina_btlog so did that, and then noticed the .e_logs folder and got the crashdumps from there too in case they are different. My .x-session-errors was empty.

i just installed the plasma browser integration extension - it seems to fail (tries to connect and failed - not surprising - it's not under plasma and possibly looking for some service). i'll see if this changes anything.

hmm that extension could be what is triggering things? maybe it's forcing built in browser notifications to use the notification dbus api? i don't think that is actually a bug - but it is triggering a bug in e (the same thing i am saying about the nvidia drivers :)). in this case there is an issue in e/efl somewhere and the job is to find it. such extensions - simple notification api usage by some client should not kill off e. even if they use the api poorly, e should handle it gracefully.

Great info, thanks!
I'll try building with asan as soon as I can and see if I can reproduce. I suspect triggering that same notification (I never saw what it was) will be tricky but maybe I can reproduce the one when toggling two YT videos fullscreen or vt switching is easier.
IIRC the only thing I had autostart which could trigger notifications, other than Chrome, is Discord. The app managing my keybard lights (ckb_next) does autostart but I don't think I've seen it trigger notifications.
I SSH:ed home and just noticed Chrome is running a process/extrension called plasma-browser-integration-host even when under E, could that be messing things up? I don't have that on my work machine which only runs E but don't know if I've gotten the same crash there (vt switching has done it though).
Is there anything else you'd like me to build differently from the Arch defaults, or perhaps some package to install?

just been trying to reproduce your crash in e .. i can't. holding down f when playing a yt video. ctrl+f on any window. holding down f11 in chrome too... toggles back and forth, no issue even with asan enabled in the build which should catch bugs that might otherwise be skipped. :( if you can build with asan - that'd help as i can't see the issue :(

so the crashdumps do seem to be an e problem. will get back to that later.

Thanks for the clarification.

so it seems this happens in e and kde. it seems to hang about more stubbornly in e but the core issue is the same. that to me says "time to talk to nvidia". you could try the nouveau drivers - but YMMV there. another option is to switch to another gpu (eg amd or intel etc.). fyi the double/triple buffering doesn't change buffering - it changes what evas ASSUMES the buffering mode is for calculating partial updates. the best is ti leave it on auto. there is no setting in e/evas to specifically use single, double, triple etc. buffering. it will thus use whatever the driver layer thinks is right (normally triple buffering).

I have had similar, if not the same, issues for months with Elite Dangerous, Doom Eternal, and pretty much any other game doing rendering, and Chrome/Chromium on all my machines running Enlightenment. Most often it happens when resizing and playing a YouTube video. The whole window rendering locks up and I have to resize again to make a few more frames render and keep doing it until it continues normally. If it gets really bad I have to reload with Ctrl+Alt+End and hope it starts rendering again, but that often ends up in a reload loop and won't stop fading back to black until I switch to a vconsole and back, which in turn causes a full lockup and if E itself doesn't force a restart I have to send it a SIGKILL (thanks you enlightenment_start for keeping my apps alive!).

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.

sorry - didnt see this here. have you tried git master? i'd need full gdb debug -0 no line numbers here... :(

Raster, first I'd like to apologize and say I'm sorry as it seems you took at least part of this critique personally. I didn't realize you are practically the only one working on this so I think I incorrectly assumed this thing was a "corporate decision" of sorts and reading back I realize I worded this much more strongly than I should have. Didn't even check who was replying to me or who the OP was... Also realized I'm chasing the master branch so I'm very much getting a snapshot of work in progress, and maybe even one that is bad at representing what it will eventually look/function like. I think trying to get work done in this frigging heat and also having to unexpectedly deal with this on my workstations didn't help. ;)

i've plugged in monitors and never seen this. everything should fade out to black (to hide the screen re-configuring with everything now black and back-light dimmed to lowest level), then e reconfigured the screen, then it fades it all back in. all screens are treated the same - desktop or laptop. same thing. the only difference is desktop screens can fade using ddc controls instead of sysfs controls. this requires ddcutil to be installed and the monitor to reliably work with ddc - but for the internal laptop screen it should also work. i've always seen this work reliably. keep in mind that when e fades to black it BOTH dims the back-light to minimum level (0 which may mean completely off for your hardware OR it may just be very dark - if you shine a bright light on the screen you should be able to see some details on the screen if it was just the back-light being off). but e ALSO RENDERS a fade to black - so basically a big black rectangle covering the whole screen that fades in from alpha 0 to solid - this causing all screens to draw black. so e does both to hide everything - that's the point. to make everything as invisible as possible while it re-configures things

Version of E was 0.24.2 built on GIT ID 7d694d6eea
EFL was 1.25.1 and GIT id d6a896ef96

some parts are unfinished. but yes - its very different. it's flat. as i explained - it's what most people demand to be "modern" so having to do it.

Maybe it'll grow on me, and some of my gripes are probably just bugs or unfinished parts that haven't been worked out yet. Still feels a bit alienating though.

I don't know what you are talking about... buttons have a shadow and a different color. they press in... when you press the button the shadow contracts and is less blurry so it looks like it presses in. i don't get the "buttons look just like labels" bit... as they don't. see below:

I just updated EFL and Enlightenment for the first time in a long time and I'm sorry but this change hit me in the face like a sledgehammer. It's a manifestation of everything wrong with modern design and this flat trend.

fixed by 7d694d6eea4a599f7d60af4c38f12a6d01fc57fa in git master

Thank you !

I worked a bit on this extension years ago, and I use it daily, if you have questions, I might be able to answer them :)

Thank you.
I have tried it. And first, I have tried to understand how it works... Maybe problem of french native language.
I am not sure to have well understood, but I do not think it is of easy use...

You could also use the Tiling module, but it is with non-enlightenment programs a pain.

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

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

i seriously think you have a driver bug. that vsync option just sets eglswapinterval to 1 instead of 0. that means egl (the xserver end of it) will wait for a vsync to swap buffers. you could try build efl with full opengl instead of egl but full opengl will use the glx swap interval api instead... so it may just end up the same. animators are still timed to vblank/sync events if possible on that platform etc. even without vsync enabled.

Yeah, I realized that. I haven't had much time for anything in the past few weeks. Hopefully it will improve and I can try to debug what is going on somehow.

Well I'm a bit stumped - without poking round to see more detailed info ... :|

Finally got back to testing the issue. CapsLock/NumLock do not affect this problem. I am on a fully up to date Arch Linux. Not to sure what to check.

At ome point i need to come back to lock screen and expanding what it can do, but i'm busy with color classes and related stuff right now.

it's not fake. it is real. pulse says so. pavucontol happens to choose to filter these out and hide them, but they are real pulse entities. emixer now does also filter them out

:)