Today
Mon, Mar 30
Can everyone check this from your side?
Hey hey hey! nice find! yeah that is now implemented :)
i guess this one should be closed, no ?
Tue, Mar 24
Mon, Mar 23
Sat, Mar 21
As of Saturday 21/03/2020 (11pm GMT)
root@Exodus:/src/efl# git diff
diff --git a/src/lib/elementary/elc_naviframe.c b/src/lib/elementary/elc_naviframe.c
index 894d88e..c9ad540 100644
--- a/src/lib/elementary/elc_naviframe.c
+++ b/src/lib/elementary/elc_naviframe.c
@@ -1553,8 +1553,8 @@ _item_push_helper(Elm_Naviframe_Item_Data *item)
{
Elm_Naviframe_Op *nfo = calloc(1, sizeof (Elm_Naviframe_Op));Fri, Mar 20
I cannot tell you the reason why this is happening, but the mouse down event is getting delivered to a rectangle and the textblock directly, which means, the entry never gets the event -> focus is never requested ... :(
- Open EDI
- Open Settings
- Build
- Try to enter text into Runtime Arguments.
Tue, Mar 17
Mon, Mar 9
test?
Feb 19 2020
An item I missed: there's a value zoom_step as part of the zoom recognizer which reports zooms as multiples of a provided step value. This currently has no way to be set, but it seems like something we should have a config value for at some point, which throws us back into the efl.config disaster.
Feb 18 2020
Feb 17 2020
Just to add some (possibly) useful info:
Feb 16 2020
I've just tested the last versions of EFL and E from git.
Everything works fine till I kill -9 efreetd process (I think that this situation is rather simple to reproduce). Then I have efreetd restarted, but in a strange state, not responding, and two zombie processes (update cache and desktop). Repeating multiple kill -9, finally I get a working efreetd, restarting E reconnects it to efreetd.
Feb 15 2020
To summarize the ideas (after remove out of scope parts)
It seems that killing efreetd (or crashing it) leaves the socket in place, so new instance has troubles to bind to it.
Feb 14 2020
I've just tested the new version on my test laptop. The situation is definitely better!! :)
I have only one instance of efreetd running, E communicates correctly with this instance, the cache is correctly updated. Restart of E does not change this situation - everything continues to work correctly.
BUT!! There is still one problem. If I kill efreetd process - it is restarted automatically, but then sometimes (not always!) it freezes, producing two or three zombies. If I kill it again - a new efreetd is started, but then it crashes (or exits) immediately and there is no new instances created. If I restart E or start another EFL app now - everything comes back to the correct situation. It seems that killing efreetd (or crashing it) leaves the socket in place, so new instance has troubles to bind to it.
The thing I don't understand - if the socket is not deleted and not unlinked - how can the situation come back to the normal state?? As I understand, with the current logic, a killed (or crashed) efreetd will prevent another instances to work...
As about deleting working socket - I cannot produce any strange effects with my test program. If I delete a working socket - the server and the client continue working as they worked before deletion, a new instance of server creates a new socket, a new instance of client correctly communicates with the new server (so I can have two pairs client-server working correctly using the same socket name, but different FDs).
unlink_before_bind is an option in the efl.net api basically it's something that cna be used to forcibly take over a socket even if something is still listening on it. it's not actually USED in efl anywhere so it's an optional code path. you can ignore this as it's not relevant because it's not enabled.
I could reproduce blocking access with my test program, but not in 100% of cases.
The key point - unlink active socket and rebind it. Sometimes the old server and the client connected to the old server continue working correctly, sometimes, stopping the second server blocks the communications with the first one.
Anyway, it seems that incorrect unlink is the root of the problem as multiple servers on the same socket is definitely not a good configuration. I see the conditional unlink in _efl_net_server_unix_bind of efl_net_server_unix, but I don't understand how and where pd->unlink_before_bind is set (it seems that _efl_net_server_unix_unlink_before_bind_set is used for it, but I don't see it used in EFL/E code).
There is a good article on the subject:
https://gavv.github.io/articles/unix-socket-reuse/
A workaround proposed on Stackoverflow:
https://stackoverflow.com/questions/7405932/how-to-know-whether-any-process-is-bound-to-a-unix-domain-socket
if you restarted e - e may have deleted the old xdg dir and replaced it - oddly with a new xdg dir of the same name. the old efreetd will eventually die when all its clients go away. i changed e to not delete on shutdown but to have enlightenment_start do that instead.
Feb 13 2020
It seems that on manual restart of Enlightenment (Ctrl-Alt-End), EFL does not read correctly XDG_RUNTIME_DIR.
The variable is set in .zshrc, manually started efreetd uses
/var/run/user/1001/.ecore/efreetd/0
Enlightenment started using startx uses it too (at least, it tries), but after a manual restart of E I see another efreetd process, using
/tmp/xdg-g5E9qA/.ecore/efreetd/0
and in the same time the first efreetd process becomes frozen, the BT is the last I've posted (efl_net_accept4).
According to sockstat, Enlightenment is connected to
/tmp/xdg-g5E9qA/.ecore/efreetd/0
a blocking accept? that's just stupid. that should not be happening. we wont be doing an accept unless the fd says its available for reads.
So, the new version does not crash anymore, it freezes.
Started from command-line, after some time running efreetd does not respond on Ctrl-C neither SIGTERM.
Backtrace:
Feb 12 2020
well i put in a "don't crash" workaround to the crash above...
Thanks! I don't see any patch attached, is it in master?
well i put in a "don't crash" workaround to the crash above... but without knowing the full flow of how it gets there, that's the best i can do.
Feb 11 2020
Valgrind works better on another PC, log attached.
Yeah, that ticket includes discussion about how to document these config values (starting at T7356#124323) but we never got to any conclusion.
The global config is in the same state of disarray as the gestures config.