- User Since
- Nov 22 2014, 7:26 AM (230 w, 5 d)
Dec 19 2014
Answering myself. So I see that the commits were backported to E19 and that a new release has been published. I updated the ebuild and the issue is hopefully over.
Dec 18 2014
Will this get fixed for E19? Is there a branch with a fix or at least a patch that applies to Enlightenment 0.19.1? I would like to provide a fully working setup for the users of my E19 ebuild for Gentoo.
Just some notes from me... The key bindings are almost unusable. One would like to use the widget to (1) see which actions have bindings set and which are those, (2) see which bindings are being used and what they mean, (3) remove found bindings and (4) add new bindings. Especially the modifications should always be explicit, i.e. the user should know when he's just listing bindings and when he's modifying them.
Dec 1 2014
677 static Eina_Bool
678 _scanner_disc(void *data UNUSED, int type UNUSED, Ecore_Con_Event_Server_Del *ev UNUSED)
680 INF("Scanner disconnected");
681 if (_scanner_poll(NULL))
683 return ECORE_CALLBACK_RENEW;
Nov 30 2014
So there's definitely a race condition somewhere at the startup of enlightenment_fm. If that race condition gets triggered, then at some point of time, _scanner_disc gets called as if in an endless loop. Using the "finish" command shows that _ecore_event_call is the function that never returns.
#4 0x0000000000409c20 in _scanner_poll (data=0x0) at src/bin/e_fm/e_fm_main_eeze.c:599
599 svr = ecore_con_server_connect(ECORE_CON_LOCAL_SYSTEM, "eeze_scanner", 0, NULL);
This will be better:
#0 0x00007ffff67bdfb7 in socket () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007ffff758fea8 in ?? () from /usr/lib64/libecore_con.so.1
#2 0x00007ffff75850d2 in ?? () from /usr/lib64/libecore_con.so.1
#3 0x00007ffff5c53600 in eo_finalize () from /usr/lib64/libeo.so.1
#4 0x00007ffff7587087 in ecore_con_server_connect () from /usr/lib64/libecore_con.so.1
#5 0x0000000000409c20 in _scanner_poll (data=0x0) at src/bin/e_fm/e_fm_main_eeze.c:599
#6 0x0000000000409fc5 in _scanner_disc (data=0x0, type=19, ev=0x4bf4dd08) at src/bin/e_fm/e_fm_main_eeze.c:681
#7 0x00007ffff7138cbc in ?? () from /usr/lib64/libecore.so.1
#8 0x00007ffff713fd79 in ?? () from /usr/lib64/libecore.so.1
#9 0x00007ffff7140047 in ecore_main_loop_begin () from /usr/lib64/libecore.so.1
#10 0x0000000000404750 in main (argc=1, argv=0x7fffffffdd88) at src/bin/e_fm/e_fm_main.c:147
Also, *whether* it happens depends on *how* I run it. For example running in gdb leads to the condition, while running in gdb with breakpoint on socket() doesn't. Looks like some sort of race conditions.
output of strace -f enlightenment_fm