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?

but if I can't launch terminology, how am I to change that setting?

Would rEc29157189f9e have fixed this as well?

Oh, right. Screenshots.

magically resolved, somehow!

magically resolved, somehow!