@netstar could you have a look at this?

I need more info about meson. What file describes how should meson set paths?
I'll try to search myself, but it is really difficult for me, some months ago I even did not know that this build system exists...

@Peter2121 Maybe you could take a look into that?

The last Git version of Enlightenment has no problem with sysactions if I force sysconfdir as mentioned, configuring meson build.
However, it seems strange for me that for FreeBSD build we need to force using /usr/local/etc as sysconfdir. I think that it should be detected automatically by meson somehow as /usr/local/etc is default configuration directory for all non-base software.

Okay that above commit was wrong.

fixed by above commit.

ok i know how to fix this, need to speak with someone to make sure it's the right fix....trivial really,

perhaps clang is not respecting the gdb options... check clang's manual for debug options... maybe you have to not even use gdb... use lldb by hand. i don't know.

By default - CLANG

ummmmm ok. well CFLAGS is set... using clang or gcc?

Yes, I compile as root

you compile as root?

Voila my root environnement (set in profile):

ummmmm then it should have filenames and line numbers there too. unless you didnt have CFLAGS set when building efl (before configure runs)...

I install EFL an E normally - autogen/configure/gmake
Nothing could strip binaries. Could it be CLANG issue?

this next issue... it's crashing deep inside the nvidia drivers. why - don't know. no symbols, data or info as to why...

those flags should do it... but it's missing the info... did something strip the binaries? did you compile and install by hand?

One more freeze, this time - with OpenGL rendering active.

What compile options should I use to have line numbers shown in the backtrace?
I used the ones from https://www.enlightenment.org/docs-efl-start :
export CFLAGS="-O2 -ffast-math -march=native -g -ggdb3"

well the freeze is in the sw rendering code path... so by switching engine you're avoiding that code path. i've never seen this on linux though. so my other comment about wanting at least a line number still stands. then i might know what is triggering it there. maybe a read-only bit of memory being written to somehow...

It seems that with OpenGL rendering the freeze is much more difficult (or impossible) to reproduce - the actions that always froze E before, don't freeze it now, I cannot reproduce it for the moment.
BTW, in the meantime I upgraded EFL and E to the last versions from Git - so maybe it helps too.
Anyway, as the problem was randomly present - I continue my tests, it's my everyday laptop, so if the problem is still here - it will be captured.

Probably, at one moment I reset the rendering to software from OpenGL I'm using normally.
I've just changed it to OpenGL (NVIDIA drivers), I'll try to reproduce the freeze.

the fascinating thing is... you're using the software engine for e? well well... must not be too slow if you are not using acceleration. :)

I noticed that E freezes regularly when I am debugging something in Netbeans on my laptop.
I rebuilt EFL and E with more debug info, I'll try to upload some backtraces here.

btw - i've been trying to update my freebsd vm to try... but network in my neck of the woods is failing to connect to pkg.freebsd.org ... something is up.

...the CPU is 100%, used by Enlightenment process.

Pretty certain this was a side-effect of no efreetd. E now will not fail without efreetd, but we have efreetd working again on FreeBSD.

Fixed a LONG time ago.

thanks - closing

in this case... your xserver is not responding to requests... notice 1 Xsync calls in 2 threads sitting and waiting for a reply...

I must also mention that this is using software compositing.

Ok, thanks raster.

hmm that crash is a patch not a crash (bt) as i'd expect... :) how can either path or name_start be null? path is a fixed size buffer (of EINA_PATH_MAX in size) so it can NEVER be NULL. so only name_start could be in. no matter what it is set by eina_file_direct_ls():