those pings are the same thing you see when you run ping on the cmdline. if you enable some device as a lock device (blueze5/bluetooth) then e will ping that device to see it's around (it's the only reliable way i've found to know this). it will also do it if you enabled "force connect". these pings are debug so you know e is actually doing this. the device you set to a lock device is obviously not around... :)

they are logged to so if you get multiple crashes... you have them all there. the latest (one at end of log) is .. the latest crash.

that backtrace implies its segfaulting inside select... which smells wrong.

@devilhorns i had long debates about people complaining "its so much more work" over a single click ... e.g. having to hit save then click something then ctrl+c ... like a long debate. so the "it gets dropped into this dir always and you get shown it to then do what u want with it" is avoiding extra clicks to keep them happy. you'd be amazed... :) but adding config to where to save is possible - but again... really is it necessary?

those gadgets mentioned above are now gone. so ... you can't do that lock screen gadgets thing anymore. might bring it back later with old gadgets.

hmmm. the code has since changed to

afb6ea1b2256a19c3c1482b4ec8106b9f99a8f44 solves this :)

not sure this is going anywhere. external lock commands are a "asking for there to be a bug and race condition". so going to remove that anyway. my other queries are to do with perhaps literally frames just not being rendered. he fade to black should hide that... so why would they see junk on the screen .. unless this is some other buffer that the driver is displaying in the swap chain - not what e rendered. some older buffer from long ago and this is displayed until enough of e and xorg wake up to render things again... this would then be a bug in the kernel and/or xorg stack. shall resolve the i3 lock issue with not having an external lock command.

Well it's not a dialog so much as showing you the screenshot where it was saved. As such - e has the ability to do that and so it does. As the shots are in a dot directory (~/.e/...) if e didn't show this you'd have no idea what happened - did it save? did it not? where did it save? You can just close the window, but it pops up for you to then USE the file as you saved it - the obvious next step is that you want to USE it. e.,g. open it it in gimp. dnd it onto an email to attach it or something... as E comes with its own file manager ... this is the obvious thing to do. EFM is literally part of e - it isn't a separate process or tool or package. the fileman module doesn't hold the file manager.. it just holds code to take existing filemanager code already in e and put it into a window of its own and place that file manager object e already has on your desktop bg etc.

looks good. :)

well it's obviously saying "no gnutls on freebsd/dragonfly". it';s explicitly disallowing it. switching it on does indeed break the logic so the solution here is.. don't use gnutls on bsd. the meson.build is explicily making the decision to use openssl here on this OS.

Chances of them re-licensing: 0.00001%. :) As I said - no need to make it a generic loader, but it does need to be off by default and an appropriate README entry describing what enabling it would mean for a system.

that isn't helpful. if you can reproduce it an actual backtrace would be nice.

no even if generic the lgplv3 will still apply as i mentioned. being lplg - the license doesnt affect efl or apps using efl, but gpl3 or lgpl3 affects the entire os requiring any gpl/lgpl3 component be user-replacable.

oooh. lgplv3 ... that'll be a problem for anyone shipping libheif... from our point of view it doesn't mater, but any system "Builder" (makes an os) now, if they want heif, essentially have to unlock the os and allow heif to be replaced.

shouldn't this then just test 32bit values on windows rather than test nothing?

i think this should just go into eina_file_mkstemp() as an ifdef for windows with a comment on why+how mkstemp is broken in mingw.

can you try...

yup. don't do that. in x .. there is no way for e to know if the xserver is active on the tty. that's private to x. e will use xrandr to control backlight if possible, but if not it has to go to /sys/... filesystem (or ddcutil) to do this and thus one e session will cause the backlight to fade/dim and even turn off because it has no clue that it is no longer the active tty owner because the xserver won't tell it. now since e16 has zero control ability over the backlight... it can't fix/restore the backlight itself like modern E can...

also - dd tests in the src/tests/eina/eina_test_lock.c ... so it's exercised and known to work. :)

Actually un-approve... you need to actually compile this before submitting it. it's full of small typos, invalid function names (with a _ where there should not be one), wrong types (small instead of capital letter), no return value from a function that returns a value... and extra ) meaning syntax parsing is broken etc.

well at least you get a nice backtrace that tells you precisely where the problem is... :)

well those logs would have been there before, but without bt's now they also have bt's. if they are happening a lot.. this will add overhead as every log needs to also scan a bt and produce it...

looks ok

looks ok to me

hmm so it only happens if launched from the java app? odd. but some race condition. are you sure it doesnt resize? could you share the src of that picker tool?

ok. so the problem dialog box is not java and has nothing to do with java other than the java app runs your dialog binary. so we actually have an efl app that is either not redrawing and i know efl will handle exposes right, so forget all of that. if you run that picker binary by hand with the same options does it do the same thing?

ordering change - yup. thumbs up. not sure wit the if (intcount == 0) had to go in to make it longer code.... but like the other patch checking init returns.. is there really a neeed?

should we be doing this.. or just removing the if (!xxxx_init()) ... as these lib inits will actually never fail...

wait... so behind i see a window. it has some wordprocessor like thing. that renders ok. that is a java app? then a dialog window with no borders appears on top. is that a java app too? or an efl dialog box? how is that dialog box shown? have you bound java to efl and use jni to call it or something? the window should be able to be resized in e:

well first - try resize your window in e - the java one that is broken. does it redraw correctly after a resize?

but does resizing in e fix ti (alt+middle mouse button anywhere resizes a window). twm allowing that window to resize smells to me like java is doing something wrong - not setting min/max size hints to make the window unresizeable...

this is not critical as well.. there are no such systems that we know about yet... they are theoretically possible... so it's not a burning red hot issue that must be solved asap.

ok. looks like a normal window but i see no mwm hints to make it borderless... if you resize the window does it get fixed up? like alt+middle mouse and drag anywhere? if its a normal client window this should work.

wait.. i need to know. is that box in the middle above he window in the background.. is that another window just with no border? override-redirect window or regular window just with borderless mwm hints?

hmmm i really can't see how that commit itself is at fault. it's some timing thing. the problem is... timing then can happen on any device anywhere and any time given kernel scheduling decisions, load, speed of hardware etc. ... and if this is the case i need to be able to reproduce it consistently to hunt it down - if i even can.

btw - does it fix itself if you open another window and drag it over this or alt+right mouse on the window to pop up a menu wondering if another draw by compositor makes it fix things up or its the src pixmap somehow still containing junk... or is it something else?

all i can imagine is it triggers a tiny timing change as it has to spew out that backtrace, which means actually this can happen on any sufficiently slow machine too... there is an environment var to disable/enable the bt

??? all this does is spew out backtraces on error logs in addition to the log. these were on by default in releases .. but not in git master... so you'd have had this behavior in releases anyway???

well i did notice that things like the input fd passing etc. have been done etc. - but as i have no config vt 0 systems and don't plan on trying any time soon... i'm more concerned about multi-screen support and some of the subsurface stacking/input things that need fixing etc. ... but i live in x11 still as i have multiple screens or regularly need them. wl is still "testing" for me.

hmm a read of that implies this actually is a large chunk of work... :) if you are going to give it a go and try make it work... great!.

nice catch - bugfix

ummm can you give me a much longer/more detailed blurb on what is going on here? what is CONFIG_VT=0? i have never encountered a system that has any kind of display and has no vt's... so if there are no vt's .. how on earth are we expected to work? not do any vt controls at all and just use input devices and kms without any vt stuff? please expand on this so i get an idea what this is about with details. :)

fbaa8984dfaf0dea27c7e865d77f10e2ae347b70 done. :)

actually this is not worth it.. just adding 1 extn. like rage's browser.c has a massively longer list of video extns... in _video_ok(). i'll add that: https://git.enlightenment.org/apps/rage.git/tree/src/bin/browser.c#n126

i just checked ecore_exe_example2.c here - ran it with no changes to efl. it passes. ... something may not be resetting the sig mask for you but it was for me...

shouldn't exec() reset sig mask?

wait for after release... :)

4b4c208d99358941cfe886bc1a87e38c2390f0bd is the commit in upstream ... i have been running it for almost a week myself with no bad side-effects. so i don't think its worse and in theory on paper, it's a fix for this... we can revert if somehow people hit issues now that i have not seen.

already in upstream :)

ok - new stab - no more heap stuff after fork and before exec:

first stab - getting rid of heap allocs in eina_file_close_from()

yes - the realloc code in eina_file_close_from can be fixed e.g. to use a fixed buffer on the stack or alloca ... but opendir() is the problem... we can't change that.

i can't find any docs on how to open a dir without an alloc (opendir) in any portable way... i suspect i may have to do a complex split by opendir before fork ... that assumes readdir() doesn't alloc anything. i hope it doesnt because the buffer should already be in DIR * ... i hope...

indeed eina_file_close_from() does call realloc... perhaps this is the problem (thus asking for details of how the child is deadlocked). perhaps this needs to change to work without malloc... actually opendir will alloc too. so that is more of a core problem. but it's necessary to close fd's... so... hmmm...

@bu5hm4n indeed - i didnt even notice that. maybe try that first?

If it can't exec... it'd exit. Like:

how does it deadlock? it never should... either the fork or exec fail and thus the fd we read on will become invalid an read returns... ?

no problems :) this is just one of those.. "don't do that" things. :)

for evlog - it wouldnt be too happy jumping through another func to get time - it'd want it inlined... we can do this for ecore_time_get but it'd have to be done in a way where we can cut the overhead as much as possible for performance sensitive areas

hmmmm... this is super performance sensitive... it can't add overhead... so i'm not so sure...

hmm. that only will detect if the relative item is the end of a list - if its the middle of another list it won't find it. that's not a lot of detected problems given it'll totally not see the problem with all the others...

we could make a verify func you can call to see a list/inlist are sane but it will only tell you when you call it. it's a tool to help narrow down the problem...

how can you detect this when it happens (in a generic way) that is very low overhead?

only one small thing... :)

mostly solved with b158abfabba220201ddb573d75ba4a48b586f152 and 534457c51d0afc9a3a50a71bb0823e786f0b1bb8 but... this could be a bit cleaner i the code was just moved into gengrid/list?

we don't need an avif example.. or even a webp example. all we need is a simple "show any given image file" example. if the reason it "we need tests" then this is a problem a avif is optional thus it'll fail when not enabled. do not take the webp example as the right thing to do here... it's the wrong thing. it's just more pain to maintain specific src for specific image formats when 1 src can do all of them (just pass in path to file on cmdline).

as per reopen... :(