- User Since
- Jan 6 2015, 5:06 AM (264 w, 1 d)
Dec 26 2019
Another interesting log records from /tmp/efreetd_host-peter.bimp.local_xxxxxx.log:
BTW, on a PC where I have the problem, /tmp is filled by efreetd_host-peter.bimp.local_djTpjB.log with the following content repeating continuously:
Dec 23 2019
Dec 7 2019
Status of sockets, having only one instance of efreetd started (PID 10298):
% sockstat -u | grep efreet peter efreetd 10298 26 stream -> /var/run/dbus/system_bus_socket peter efreetd 10298 29 stream /tmp/xdg-9U9z02/.ecore/efreetd/0 peter efreetd 10298 995 stream/tmp/xdg-9U9z02/.ecore/efreetd/0 peter enlightenm 9403 35 stream -> /tmp/xdg-9U9z02/.ecore/efreetd/0
Is it normal that there are two lines for the same PID of efreetd (10298) and the same socket (/tmp/...) with different FDs - 29 and 995?
Sure, we are going the good direction, thank you :)
If I kill ALL efreetd processes and start ephoto - I finish with one or two efreetd processes, consuming 100% of CPU.
The console log:
If I attach a debugger - I see the same backtrace that I've mentioned in the previous post.
With the new revision I cannot reproduce the crash. Starting ephoto does not produce several instances of efreetd.
If I manually start many efreetd instances (just 'efreetd' in terminology, without arguments) - at one moment I see multiple instances started, consuming 100% of CPU:
9512 peter 92 20 42024 31416 T 0.0 0.4 0:51.17 /usr/local/bin/efreetd 9590 peter 120 19 42024 32584 R 99.9 0.4 7:49.05 /usr/local/bin/efreetd 9607 peter 120 19 42024 32584 R 96.9 0.4 7:48.64 /usr/local/bin/efreetd 9624 peter 52 19 42024 32568 S 0.0 0.4 0:00.68 /usr/local/bin/efreetd
The processes don't respond on SIGTERM.
If I attach a debugger - I see the following backtrace:
(lldb) bt * thread #1, name = 'efreetd' * frame #0: 0x00000008005c805a libc.so.7`_select + 10 frame #1: 0x00000008003f6522 libthr.so.3`___lldb_unnamed_symbol44$$libthr.so.3 + 66 frame #2: 0x000000080033126a libecore.so.1`_ecore_main_select(obj=0x00004000000002fe, pd=0x00000008016130b0, timeout=<unavailable>) at ecore_main.c:1859 frame #3: 0x000000080032ffa1 libecore.so.1`_ecore_main_loop_iterate_internal(obj=0x00004000000002fe, pd=0x00000008016130b0, once_only=0) at ecore_main.c:2461 frame #4: 0x000000080033012d libecore.so.1`_ecore_main_loop_begin(obj=0x00004000000002fe, pd=0x00000008016130b0) at ecore_main.c:1200 frame #5: 0x00000008003356b6 libecore.so.1`_efl_loop_begin(obj=0x00004000000002fe, pd=0x00000008016130b0) at efl_loop.c:57 frame #6: 0x0000000800335136 libecore.so.1`efl_loop_begin(obj=0x00004000000002fe) at efl_loop.eo.c:28 frame #7: 0x0000000800330223 libecore.so.1`ecore_main_loop_begin at ecore_main.c:1285 frame #8: 0x000000000020449c efreetd`main(argc=<unavailable>, argv=<unavailable>) at efreetd.c:82 frame #9: 0x000000000020411b efreetd`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1.c:76
Nothing is shown in command line.
The cache is still not updated, Enlightenment shows an error on start: 'Efreetd cannot be connected to'. The socket '=0' is present in /tmp/xdg-9U9z02/.ecore/efreetd
When I start ephoto from terminology I see the following output in console:
There are no previews in ephoto.
Dec 6 2019
It's definitely a step ahead, I don't see multiple instances of efreetd started.
But the problem of SIGSEGV is still here.
To produce it:
- start E (startup error - cannot connect to efreetd)
- only one instance of efreetd is present
- start ephoto - still one instance of efreetd is present
- start efreetd from command line - it exits immediately
- start efreetd several times from command line - it exits after a 1-2 sec delay
- the only started efreetd process is consuming 100% of CPU
- start efreetd several times from command line - one of them is crashed with the same error as before, the same coredump, zeros in 'value'.
I could catch the same crash:
Nov 8 2019
Fixed in Meson, tested OK. Hope the new version of Meson will be released soon.
Nov 5 2019
Probably fixed in Meson's master: https://github.com/mesonbuild/meson/pull/4410
I need some time to test it...
Oct 31 2019
OK, I've got it.
There is a hack in the ports system, it redirects *.pc from lib to libdata during stage (and install).
So, probably, we only need to put some info into the docs about the behavior change from autotools to meson.
Right now, after install, EFL libs are not available for building software under FreeBSD. Even Enlightenment does not build. I think it is very bad. Asking a user who wants to build Enlightenment to add a custom path for pkg config is a bad idea. It is a regression passing to meson build from autotools. If it can be solved on EFL level - IMHO it should be solved. If you consider that it should be fixed on meson level - try to ask it to meson devs.
Anyway, it must be patched in FreeBSD port, if not - EFL 1.23 will not be accepted in ports tree. The standard path for *.pc files in FreeBSD - /usr/local/libdata/pkgconfig
Oct 11 2019
Aug 7 2019
Me too, sometimes I have problems with window switcher. It does not show the list, but only the next window icon & name. But I don't need to restart the session, the next invoking the switcher is normally correct.
And UI does not hang for me with the last versions of E/EFL.
I don't see the segmentation fault closing emixer on my laptop.
FreeBSD 11.2-RELEASE-p9 Enlightenment 0.23.0.alpha EFL 1.22.2
Apr 15 2019
cederom, you should begin with full uninstall E and EFL, port version of EFL is really outdated. Then you should download the last versions from enlightenment.org (or checkout from Enlightenment git) and build both EFL and E from sources.
I'm on git versions (dated some months ago) on FreeBSD 11.2. It's stable, I'm using it every day ~12hrs by day without freezes. I tested everything on FreeBSD 12 too without problems.
I did not (yet) tested the last released version of EFL.
You can ask for help in maillist if you have problems with build.
Mar 3 2019
OK, with if sys_linux == true it works better ;)
I could build EFL, Enlightenment and Terminology, everything works fine on FreeBSD 12.
So, I took my test PC (FreeBSD 12) , I've uninstaled all EFL stuff, I've cloned EFL repo and I've patched src/lib/ecore_file/meson.build like in Diff 19894.
Then I've declared the following environment variables:
Libinotify is present in FreeBSD as port:
You can see the limitations of this library in pkg-message section of this page. This library is used for 50+ ports and they manage to use it correctly. I referenced two projects that added support of FreeBSD's inotify without hacks: polybar, gerbera It does not seem to me that they needed to work hard to add this support ;) Anyway, if EFL cannot use it correctly under FreeBSD - we need a meson option to disable it without removing headers.
Make sure you remove any package that is including inotify headers because the EFL build will see these headers and assume we can use inotify but we cannot use it on FreeBSD. If you have inotify.h in /usr/local/include or elsewhere, remove it, or the package that is pulling in this bogus header.
Mar 2 2019
Sorry, netstar, the problem explained in this post is still present, building with your options.
Errors about inotify_* changed to warnings (will it run correctly after build?)
...and a commit to add FreeBSD libinotify support to gerbera:
There is a thread in FreeBSD forum about porting polybar, they had libinotify problems too...
If I remove libinotify I get another error:
Mar 1 2019
FAILED: src/bin/efreet/efreet_desktop_cache_create cc -o src/bin/efreet/efreet_desktop_cache_create 'src/bin/efreet/d57513e@@efreet_desktop_cache_create@exe/efreet_desktop_cache_create.c.o' -Wl,--as-nee ed -Wl,-O1 -O2 -ffast-math -march=native -g -ggdb3 -Wl,--start-group src/lib/efreet/libefreet.so.1.22.0 src/lib/eina/libeina.so.1.22.0 src/lib/eo/libeo. o.1.22.0 src/lib/efl/libefl.so.1.22.0 src/lib/ecore/libecore.so.1.22.0 src/lib/eet/libeet.so.1.22.0 src/lib/emile/libemile.so.1.22.0 src/lib/ecore_file/ ibecore_file.so.1.22.0 -ldl /usr/local/lib/libunwind-generic.so /usr/local/lib/libunwind.so -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -Wl,--end- roup -pthread '-Wl,-rpath,$ORIGIN/../../lib/efreet:$ORIGIN/../../lib/eina:$ORIGIN/../../lib/eo:$ORIGIN/../../lib/efl:$ORIGIN/../../lib/eet:$ORIGIN/../.. lib/emile:$ORIGIN/../../static_libs/lz4:$ORIGIN/../../lib/ecore:$ORIGIN/../../static_libs/buildsystem:$ORIGIN/../../lib/ecore_con:$ORIGIN/../../lib/eldb s:$ORIGIN/../../static_libs/http-parser:$ORIGIN/../../lib/ecore_file:$ORIGIN/../../lib/ecore_ipc' -Wl,-rpath-link,/usr/home/peter/Programming/Prog-EFL/t st-efl/efl/build/src/lib/efreet:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/eina:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/b ild/src/lib/eo:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/efl:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/eet:/ sr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/emile:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/static_libs/lz4:/usr/hom /peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/ecore:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/static_libs/buildsystem:/usr/ho e/peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/ecore_con:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/eldbus:/usr/home/peter Programming/Prog-EFL/test-efl/efl/build/src/static_libs/http-parser:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/ecore_file:/usr/home peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/ecore_ipc src/lib/ecore_file/libecore_file.so.1.22.0: undefined reference to `inotify_add_watch' src/lib/ecore_file/libecore_file.so.1.22.0: undefined reference to `inotify_init' src/lib/ecore_file/libecore_file.so.1.22.0: undefined reference to `inotify_rm_watch' cc: error: linker command failed with exit code 1 (use -v to see invocation)
Do you have libinotify installed?
config command was:
meson setup --wipe build -Decore-imf-loaders-disabler=xim,scim,ibus -Db_lundef=false \ -Dxinput22=true -Dbuffer=false -Dfb=false -Ddrm=false \ -Dtslib=false -Dharfbuzz=true -Dwl=false -Dnetwork-backend=connman \ -Devas-loaders-disabler= -Dbindings=cxx,luajit -Dbuild-examples=false \ -Dsystemd=false -Deeze=false
I used the following command to configure the build:
Sorry, the workaround does not work.
I deleted build directory and reconfigured meson with the proposed option.
The build still fails.
[453/3977] Linking target src/lib/ecore/libecore.so.1.22.0.
Feb 28 2019
vtorri, I don't think it's related as in the bug they discuss a runtime problem, but we have a build time problem. I've just declared the variable as 'extern' and the build passed, E works correctly with the compiled version of EFL (I'm using it since 2 days). BUT, I don't know if somewhere this function was used, so MAYBE we are concerned by 220103 bug too.
Feb 27 2019
Nothing changed adding the header.
Nothing changed adding the unistd.h header.
Anyway, there is no
variable declared in system's unistd.h.
I cannot find any header with such declaration.
Feb 26 2019
Nov 22 2018
I confirm that this commit solved the problem.
Thanks a lot, raster!
Nov 13 2018
I mentioned one interesting thing more.
When I switch to another task, in case of a lost mouse click - not only keyboard works correctly in the active window, but mouse scroll works correctly too. Only mouse clicks (left and right buttons, additional buttons too) are lost for the first click. So, for example, if I switch to another window using mouse and WinList - I cannot use WinList again immediately, the first click of additional button is lost, WinList does not get active.
Nov 11 2018
Sure, the click to dismiss winlist must be lost, I don't count it. I perfectly understand that it is used like 'escape' key. I mean the next click is lost.
I've just used 'git clone' command to clone the repository.
I think I'm on 'master' as I see your last modif in src/modules/winlist/e_mod_main.c:
static Eina_Bool _e_mod_action_winlist_wheel_cb(...
Nov 10 2018
Sorry, raster, the problem is still present with the GIT version with your modifs.
Only the first time switching windows with mouse and WinList the focus is not lost. Then it is always lost till I use once Alt-Tab. Then it is not lost once etc.
Nov 7 2018
For me it is neither related to the system charge nor to CPU use by Enlightenment.
It seems to be a bug in WinList module as it cannot be produced by keyboard manipulations, only by mouse.
Nov 6 2018
Some additional tests with EFL 1.21.1, Enlightenment 0.22.4 on FreeBSD 12BETA2.
The problem is still present.
Really interesting point is that the problem is not present on FIRST task switch. If I open some windows and then use WinList with mouse only - everything works as expected. If I then retry - the focus is lost as explained. And if then I use WinList with keyboard (Alt-Tab) - the next time I use it with mouse it works OK - once.
It seems that the problem is NOT present in GIT version.
It would be nice to see a new release with the fix ;)
Nov 1 2018
Oct 26 2018
Mar 29 2018
I've just tested it a little bit more.
The problem is really simple to reproduce if I click inside winlist, choosing a window to activate. The area of winlist where I click does not matter, this click just closes winlist.
- Additional mouse button to activate winlist
- Mouse wheel to choose window
- Mouse left-click inside winlist
- Selected window becomes active (decoration), but the first click inside the window does not work (no focus), only the second one.
Mar 15 2018
@netstar, you closed it the 1 Mars ;)
...and yes, I found how to FORCE_SYNC_RENDER, you mentioned it later here (I did not see).
Were your E fixes included in 0.22.2? What will be the version of EFL with your fixes? I want to ping email@example.com to update the ports, but it would be better to wait the both products updated.
Mar 14 2018
Finally, I could test the last E build with the last EFL on my test laptop with FreeBSD 12 and HDD.
The stability is greatly improved, I could not freeze it. So I think that the problem is solved.
Note that I did NOT set _FORCE_SYNC_RENDER (I still don't understand how to do it).
The previous versions of EFL were removed with
ninja -C build uninstall
Digging into /usr/local/lib, I found some EFL-related dirs without files inside. I removed all these dirs. Then I cloned again EFL repository and I could build it. I'll test again after some commits in EFL tree, pulling the modifications.
Mar 12 2018
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...
@felipealmeida, what log do you want to see?
I still have the error I mentioned in the first post here, only the filename changes. These files (*.hh) do not exist in source tree (that's why compiler segfaults).
It seems that the build system mixed *.h and *.hh files somehow...
Mar 11 2018
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.
Sorry, still does not build with
Mar 8 2018
Mar 1 2018
The file lib/evas/canvas/efl_canvas_surface_x11.eo.hh is not present in my src.
In the old directory lib/efl/interfaces/efl_gfx_gradient_linear.eo.hh is not present, in the new one it is present.
Some strange things are happening during the build...
I cloned again the repository (the first try was 'git pull' to the existing dir) and the error has changed:
I don't see in your commit the patch for src/bin/e_object.c, is it forgotten?
Feb 28 2018
The old gadget is correctly showing the current frequency with digits, so I can see that it changes (powerd is active).
The new one now works exactly as the old one - the pointer is moving in opposite direction: by default (max frequency) it's on minimum, when the frequency decreases - it turns right to reach the right position when the frequency is minimal. For me the minimum is 800MHz, the maximum is 2600MHz (I can see it on the old gadget).
BTW, visually it is not really cool - on the min and max positions the pointer is not really visible.
...And the digits on the old gadget was not so bad idea ;)
The problem is still present in last Enlightenment (GIT) built with last EFL (GIT).
The most simple way to reproduce - add mouse bindings like I described, then start two windows on the same screen (Firefox and Thunderbird), then from Firefox activate 'Windows List' with mouse button - Thunderbird is selected and put in front), then click-left somewhere inside Thunderbird. 'Windows List' will close, Thunderbird will get focus. Click somewhere inside Thunderbird window (for example, to change the active folder) - nothing happens. The second click in the same place will work correctly.
EFL & E from GIT on FreeBSD 11.1.
New CPUClock gadget still does not work correctly, the old one neither :(
I've pulled EFL and Enlightenment from GIT, applied your patch and installed.
Then I tried to install a new app and access the main menu immediately after install. I always had a freeze on this operation, I have no such freeze today. So it seems to go better.
Tomorrow I'll try to test on another laptop with FreeBSD 12.0 installed.
Feb 3 2018
Is there any possible workaround in the current state?
Could you prepare a small tool to put in evidence the popen problem? So I can try to open a ticket in FreeBSD tracker...
Maybe there are some side effects - using popen in unusual way? I doubt that nobody found this FreeBSD problem before...
It seems that it is!!
I deleted all themes with svg files and deleted 'scalable' dir from 'hicolor', so there is no svg files in /usr/local/shared. Then I killed efreetd, deleted efreetd cache and efreetd socket and restarted the laptop. After reboot I cannot reproduce the problem of main menu freezes, new apps installed OK and new icons are shown in the menu.
Feb 1 2018
I've just tested it with EFL from git of 30/01/18 23:28 - still crashes.
It's on FreeBSD 12-CURRENT (PCBSD flavor).
Sorry, still crashes for me (T6647)
Jan 31 2018
I've just tested on 12-CURRENT with EFL and E from git - the problem is still here, simple to reproduce.
Jan 28 2018
Jan 25 2018
Yes, I can interact with other windows, but no window has focus.
Nov 26 2017
Just to precise that sometimes the focus is lost after closing a window too. Another window becomes active, but does not get a focus.
Nov 18 2017
Nov 6 2017
Enlightenment never starts under Valgrind on FreeBSD, I cannot produce the logs.
Oct 29 2017
Should I re-post the Valgrind log to other ticket? Is it really useful?
Well, I tried to start E with Valgrind.
Under Xephyr it does not work at all (probably the problem of support of OpenGL under Xephyr).
So, I modified enlightenment.desktop to start it from lightdm. And it does not initialize correctly. I was waiting for 30 mins, then I killed the process. It was restarted automatically, but again - it did not finish the initialization. Maybe, I do something incorrectly.
The log file is attached.
Oct 28 2017
Sorry, another try to freeze it was "successful":
Let me know if you need any debugs on FreeBSD 11.0.
I cannot reproduce the freeze on git version of E, compiled with "-g -ggdb3 -O0" CFLAGS.
netstar, what about you?
netstar, do you mean I should try git version of E?
Xephyr is not installed on my system, Valgrind neither. I'll try to debug it tonight, having more time.
Could fvwm be replaced by LXDE? I have E and LXDE installed already, fvwm must be added...
netstar, I'm on FreeBSD 11.0-RELEASE-p8. I use lightdm to start E. Valgrind is not installed, but I can try to add it and debug E with it. But I need the detailed instructions (used it once, some years ago on RPi to debug a small app...) I have no idea - how to correctly start E under Valgrind.
so i doubt it's that.
Raster, how can you explain that I was working 10 hours on the PC, using the menu many times, than I added (manually) a desktop file and the next time the menu freezes my PC?
Nvidia, the driver is nvidia-driver-340-340.102.
I just tried to open the menu, nothing more. At the moment of the crash, E was opening the right part of the menu, this part stays semi-transparent on crash, never completely painted.
Oct 27 2017
I think to reproduce this problem for sure when I add a *.desktop file in /usr/local/share/applications
Then, if I try to open the main menu - my E always freezes. Always. As the method of tracking the changes in the directory is different on *BSD - it could explain why the problem is not present in Linux.
Oct 25 2017
I did not see any relation with minimizing/restoring windows.
On the Cpufreq gadget (in a shelf) the arrow does not move at all (stays on minimum) but the digits show the actual frequency.
On the CPUClock gadget (in a bryce) arrow moves in the opposite direction.
One more freeze, slightly different