I have a weird issue with certain application icons using efl 1.22 or latter not showing in menus and elsewhere in Moksha. This is also true using e17 (if fixed to compile with efl 1.22) but in my brief tests everything works right in e22. Other than e17 I did not test any other e version. Since e17 has this issue it seems unrelated to all the changes moksha has had since forking e17.
Screenshots of broken icons: https://imgur.com/eCDTpIE https://imgur.com/DN3IhAL This was reported to me by a user and two such apps are circuslinux and bouncy. Both apps installed using apt on a Ubuntu 18.04 base. What these apps have in common is they use xpm icons located in /usr/share/pixmaps/ on Debian based distros. This may or may not be relevant and there may or may not be apps causing this or a similar issue with icons of a different format or stored elsewhere. Clearly efl can display xpm icons correctly regardless of location. I wrote test code to prove that but e22 itself proves it. Also of interest if i create png icons for these apps and store in /usr/share/icons and delete the xpm icons everything works as expected. To make matters worse after one opens the menu and mouses over the menu for these apps a few times, at some point latter moksha/e17 seg faults or freezes up. I have spent several hours talking with raster about this issue and he has made 2 commits he thought might help. But sadly they didn't change much. Still no icons displayed and still segfaults issues. Naturally I spent some time looking at this issue and e22 commits before talking to raster about it all. I tend to be reluctant to ask questions or seek help. I am uncertain whether this is an actual efl bug or perhaps changes in efl necesitate some some changes in moksha/e17. Raster suggested I post the issue in this mailing list, because he seems about as confused as me about it all. It should be noted Raster didn't directly look at the issue by installing either moksha or e17. Perhaps tho it may be necessary to get to the bottom of this issue. But even if not I can provide you with whatever info you need. Below is all relevant info I know. I will be using moksha source code here and for reference it is located https://github.com/JeffHoogland/moksha I also use an lubuntu 18.04 VM as my test machine since Bodhi 5.x is ubuntu 18.04 based. Meson I install from a deb file I made: http://packages.bodhilinux.com/bodhi/pool/b5main/m/meson/ and I always install all packages (efl, moksha and so on with prefix=/usr. In compilation I will be adding -g3 -O0 to CFLAGS for debugging purposes here. If anyone actually goes to the trouble of trying to set up a test environment for this issue and has issues install moksha correctly just ask me and I can help. Should be straightforward for y'all as it is just a modified e17. Git bisect reveals commit evas image: fix a bug in image preloading is the commit that breaks things here. https://git.enlightenment.org/core/efl.git/commit/?id=423d8a22961436299df0feca17b03544678b8c0f If I examine ~/.cache/efreet, it seems efreet is picking things up correctly. For example: test@test-VirtualBox:~/.cache/efreet$ eet -d icons___efreet_fallback_test-VirtualBox.eet bouncy group "Efreet_Cache_Fallback_Icon" struct { group "icons" var_array { count 1; value "icons" string: "/usr/share/pixmaps/bouncy.xpm"; } } Uncomment the CACHEDUMP define in src/lib/evas/cache/evas_cache_image.c, for the icons in question I have in efl at the commit that breaks things or latter: DATA : 0: 1729b, 32x 32 alloc[ 0x 0] [/usr/share/pixmaps/circuslinux-icon.xpm] [(null)] DATA : 0: 1729b, 32x 32 alloc[ 0x 0] [/usr/share/pixmaps/bouncy.xpm] [(null)] Whereas when things work (before the aforementioned commit) : DATA : 0: 4669b, 32x 32 alloc[ 32x 32] [/usr/share/pixmaps/circuslinux-icon.xpm] [(null)] DATA : 0: 4669b, 32x 32 alloc[ 32x 32] [/usr/share/pixmaps/bouncy.xpm] [(null)] Raster seems to think this may not be related but it seems suspicious to me. In gdb I have observed the seg fault appears to occur in _cache_prune function in lib/evas/common/evas_image_scalecache.c https://pastebin.com/T6QKqr1H For reference, this bt was using efl in git at commit: test@test-VirtualBox:~/Code/efl$ git show commit bf58531dbaacb9ff78583278b04785e85a4c34cd (HEAD -> master, origin/master, origin/HEAD) Author: Daniel Kolesa <d.kol...@samsung.com> Date: Sat Aug 31 14:11:48 2019 +0200 eolian: fix validation of ownability with hashes If I build efl and moksha with address sanitizer enabled as per https://phab.enlightenment.org/T8137. Compiled with gcc, then the relevant crash is: ==1636==ERROR: AddressSanitizer: heap-use-after-free on address 0x60b000122190 at pc 0x7f0e13a51f5c bp 0x7fff4d4f7310 sp 0x7fff4d4f7300 WRITE of size 8 at 0x60b000122190 thread T0 #0 0x7f0e13a51f5b in eina_inlist_remove ../src/lib/eina/eina_inlist.c:353 #1 0x7f0e14ed9302 in evas_common_rgba_image_scalecache_dirty ../src/lib/evas/common/evas_image_scalecache.c:189 #2 0x7f0e14ed5195 in _evas_common_rgba_image_unload ../src/lib/evas/common/evas_image_main.c:803 #3 0x7f0e152fe13a in _evas_cache_image_entry_delete ../src/lib/evas/cache/evas_cache_image.c:180 #4 0x7f0e15305ae5 in evas_cache_image_flush ../src/lib/evas/cache/evas_cache_image.c:1359 #5 0x7f0e1530093a in evas_cache_image_set ../src/lib/evas/cache/evas_cache_image.c:573 #6 0x7f0e14ed654a in evas_common_image_set_cache ../src/lib/evas/common/evas_image_main.c:1009 #7 0x7f0e14e22ccc in eng_image_cache_flush ../src/modules/evas/engines/software_generic/evas_engine.c:3026 #8 0x7f0e14fb07cb in _evas_canvas_image_cache_flush ../src/lib/evas/canvas/evas_main.c:1148 #9 0x7f0e14fc30ee in evas_canvas_image_cache_flush ../src/lib/evas/canvas/evas_canvas_eo.c:256 #10 0x7f0e14fc6980 in evas_image_cache_flush ../src/lib/evas/canvas/evas_canvas_eo.legacy.c:305 #11 0x5610b4351f14 in e_canvas_cache_flush /home/test/Code/moksha/src/bin/e_canvas.c:88 #12 0x5610b435263e in _e_canvas_cb_flush /home/test/Code/moksha/src/bin/e_canvas.c:167 #13 0x7f0e145cf9fe in _ecore_poller_cb_timer ../src/lib/ecore/ecore_poller.c:158 #14 0x7f0e145d3b40 in _ecore_call_task_cb ../src/lib/ecore/ecore_private.h:469 #15 0x7f0e145d4639 in _ecore_timer_legacy_tick ../src/lib/ecore/ecore_timer.c:160 #16 0x7f0e10c4a678 in _event_callback_call ../src/lib/eo/eo_base_class.c:1737 #17 0x7f0e10c4b018 in _efl_object_event_callback_call ../src/lib/eo/eo_base_class.c:1821 #18 0x7f0e10c4b20c in efl_event_callback_call ../src/lib/eo/eo_base_class.c:1824 #19 0x7f0e145d74fe in _efl_loop_timer_expired_call ../src/lib/ecore/ecore_timer.c:644 #20 0x7f0e145d706f in _efl_loop_timer_expired_timers_call ../src/lib/ecore/ecore_timer.c:597 #21 0x7f0e1451f345 in _ecore_main_loop_iterate_internal ../src/lib/ecore/ecore_main.c:2376 #22 0x7f0e14519351 in _ecore_main_loop_begin ../src/lib/ecore/ecore_main.c:1199 #23 0x7f0e1452d1a1 in _efl_loop_begin ../src/lib/ecore/efl_loop.c:57 #24 0x7f0e14532560 in efl_loop_begin src/lib/ecore/efl_loop.eo.c:28 #25 0x7f0e1451980b in ecore_main_loop_begin ../src/lib/ecore/ecore_main.c:1284 #26 0x5610b42af1be in main /home/test/Code/moksha/src/bin/e_main.c:1154 #27 0x7f0e12e48b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) #28 0x5610b42a6769 in _start (/usr/bin/enlightenment+0x9c769) 0x60b000122190 is located 0 bytes inside of 104-byte region [0x60b000122190,0x60b0001221f8) freed by thread T0 here: #0 0x7f0e188e97b8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7b8) #1 0x7f0e14ed9400 in evas_common_rgba_image_scalecache_dirty ../src/lib/evas/common/evas_image_scalecache.c:204 #2 0x7f0e14ed5195 in _evas_common_rgba_image_unload ../src/lib/evas/common/evas_image_main.c:803 #3 0x7f0e152fe13a in _evas_cache_image_entry_delete ../src/lib/evas/cache/evas_cache_image.c:180 #4 0x7f0e15305ae5 in evas_cache_image_flush ../src/lib/evas/cache/evas_cache_image.c:1359 #5 0x7f0e1530093a in evas_cache_image_set ../src/lib/evas/cache/evas_cache_image.c:573 #6 0x7f0e14ed654a in evas_common_image_set_cache ../src/lib/evas/common/evas_image_main.c:1009 #7 0x7f0e14e22ccc in eng_image_cache_flush ../src/modules/evas/engines/software_generic/evas_engine.c:3026 #8 0x7f0e14fb07cb in _evas_canvas_image_cache_flush ../src/lib/evas/canvas/evas_main.c:1148 #9 0x7f0e14fc30ee in evas_canvas_image_cache_flush ../src/lib/evas/canvas/evas_canvas_eo.c:256 #10 0x7f0e14fc6980 in evas_image_cache_flush ../src/lib/evas/canvas/evas_canvas_eo.legacy.c:305 #11 0x5610b4351f14 in e_canvas_cache_flush /home/test/Code/moksha/src/bin/e_canvas.c:88 #12 0x5610b435263e in _e_canvas_cb_flush /home/test/Code/moksha/src/bin/e_canvas.c:167 #13 0x7f0e145cf9fe in _ecore_poller_cb_timer ../src/lib/ecore/ecore_poller.c:158 #14 0x7f0e145d3b40 in _ecore_call_task_cb ../src/lib/ecore/ecore_private.h:469 #15 0x7f0e145d4639 in _ecore_timer_legacy_tick ../src/lib/ecore/ecore_timer.c:160 #16 0x7f0e10c4a678 in _event_callback_call ../src/lib/eo/eo_base_class.c:1737 #17 0x7f0e10c4b018 in _efl_object_event_callback_call ../src/lib/eo/eo_base_class.c:1821 #18 0x7f0e10c4b20c in efl_event_callback_call ../src/lib/eo/eo_base_class.c:1824 #19 0x7f0e145d74fe in _efl_loop_timer_expired_call ../src/lib/ecore/ecore_timer.c:644 #20 0x7f0e145d706f in _efl_loop_timer_expired_timers_call ../src/lib/ecore/ecore_timer.c:597 #21 0x7f0e1451f345 in _ecore_main_loop_iterate_internal ../src/lib/ecore/ecore_main.c:2376 #22 0x7f0e14519351 in _ecore_main_loop_begin ../src/lib/ecore/ecore_main.c:1199 #23 0x7f0e1452d1a1 in _efl_loop_begin ../src/lib/ecore/efl_loop.c:57 #24 0x7f0e14532560 in efl_loop_begin src/lib/ecore/efl_loop.eo.c:28 #25 0x7f0e1451980b in ecore_main_loop_begin ../src/lib/ecore/ecore_main.c:1284 #26 0x5610b42af1be in main /home/test/Code/moksha/src/bin/e_main.c:1154 #27 0x7f0e12e48b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) previously allocated by thread T0 here: #0 0x7f0e188e9d38 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded38) #1 0x7f0e14eda6d7 in _sci_find ../src/lib/evas/common/evas_image_scalecache.c:371 #2 0x7f0e14edb5be in evas_common_rgba_image_scalecache_prepare ../src/lib/evas/common/evas_image_scalecache.c:591 #3 0x7f0e14e1cb04 in eng_image_draw ../src/modules/evas/engines/software_generic/evas_engine.c:2404 #4 0x7f0e14fec3b6 in _draw_image ../src/lib/evas/canvas/evas_object_image.c:1792 #5 0x7f0e14ff781b in _evas_image_render ../src/lib/evas/canvas/evas_object_image.c:2636 #6 0x7f0e14ff26f7 in evas_object_image_render ../src/lib/evas/canvas/evas_object_image.c:2279 #7 0x7f0e1516d15b in evas_render_mapped ../src/lib/evas/canvas/evas_render.c:2286 #8 0x7f0e151776f1 in evas_render_updates_internal_loop ../src/lib/evas/canvas/evas_render.c:3098 #9 0x7f0e1517c93d in evas_render_updates_internal ../src/lib/evas/canvas/evas_render.c:3563 #10 0x7f0e15180593 in _evas_canvas_render_async ../src/lib/evas/canvas/evas_render.c:3955 #11 0x7f0e14fbef2a in evas_canvas_render_async ../src/lib/evas/canvas/evas_canvas_eo.c:168 #12 0x7f0e14fc66ce in evas_render_async ../src/lib/evas/canvas/evas_canvas_eo.legacy.c:179 #13 0x7f0dfe97cf90 in _ecore_evas_x_render ../src/modules/ecore_evas/engines/x/ecore_evas_x.c:742 #14 0x7f0e167392ae in _ecore_evas_idle_enter ../src/lib/ecore_evas/ecore_evas.c:293 #15 0x7f0e14513af7 in _ecore_call_task_cb ../src/lib/ecore/ecore_private.h:469 #16 0x7f0e14513bd8 in _ecore_factorized_idle_process ../src/lib/ecore/ecore_idler.c:35 #17 0x7f0e10c4a678 in _event_callback_call ../src/lib/eo/eo_base_class.c:1737 #18 0x7f0e10c4b018 in _efl_object_event_callback_call ../src/lib/eo/eo_base_class.c:1821 #19 0x7f0e10c4b20c in efl_event_callback_call ../src/lib/eo/eo_base_class.c:1824 #20 0x7f0e1451f489 in _ecore_main_loop_iterate_internal ../src/lib/ecore/ecore_main.c:2411 #21 0x7f0e14519351 in _ecore_main_loop_begin ../src/lib/ecore/ecore_main.c:1199 #22 0x7f0e1452d1a1 in _efl_loop_begin ../src/lib/ecore/efl_loop.c:57 #23 0x7f0e14532560 in efl_loop_begin src/lib/ecore/efl_loop.eo.c:28 #24 0x7f0e1451980b in ecore_main_loop_begin ../src/lib/ecore/ecore_main.c:1284 #25 0x5610b42af1be in main /home/test/Code/moksha/src/bin/e_main.c:1154 #26 0x7f0e12e48b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) SUMMARY: AddressSanitizer: heap-use-after-free ../src/lib/eina/eina_inlist.c:353 in eina_inlist_remove Shadow bytes around the buggy address: 0x0c168001c3e0: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa 0x0c168001c3f0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa fa 0x0c168001c400: fa fa fa fa fa fa fd fd fd fd fd fd fd fd fd fd 0x0c168001c410: fd fd fd fd fa fa fa fa fa fa fa fa fd fd fd fd 0x0c168001c420: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa =>0x0c168001c430: fa fa[fd]fd fd fd fd fd fd fd fd fd fd fd fd fa 0x0c168001c440: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd 0x0c168001c450: fd fd fd fd fd fa fa fa fa fa fa fa fa fa fd fd 0x0c168001c460: fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa 0x0c168001c470: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd 0x0c168001c480: fd fa fa fa fa fa fa fa fa fa fd fd fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==1636==ABORTING test@test-VirtualBox:~$ ================================================================= ==1637==ERROR: LeakSanitizer: detected memory leaks Direct leak of 920 byte(s) in 5 object(s) allocated from: #0 0x7fe56c4f9d38 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded38) #1 0x7fe563933b64 (<unknown module>) Direct leak of 520 byte(s) in 13 object(s) allocated from: #0 0x7fe56c4f9b50 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb50) #1 0x7fe56394cf71 (<unknown module>) Direct leak of 256 byte(s) in 2 object(s) allocated from: #0 0x7fe56c4f9d38 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded38) #1 0x7fe56b81281e in ecore_ipc_client_add ../src/lib/ecore_ipc/ecore_ipc.c:295 #2 0x7fe56b81e2f3 in _ecore_ipc_server_client_add ../src/lib/ecore_ipc/ecore_ipc.c:1340 #3 0x7fe569893678 in _event_callback_call ../src/lib/eo/eo_base_class.c:1737 #4 0x7fe569894018 in _efl_object_event_callback_call ../src/lib/eo/eo_base_class.c:1821 #5 0x7fe56989420c in efl_event_callback_call ../src/lib/eo/eo_base_class.c:1824 #6 0x7fe569e4fc0e in _efl_net_server_fd_efl_net_server_client_announce ../src/lib/ecore_con/efl_net_server_fd.c:504 #7 0x7fe569e4626a in efl_net_server_client_announce src/lib/ecore_con/efl_net_server.eo.c:64 #8 0x7fe569e9a0cf in _efl_net_server_unix_efl_net_server_fd_client_add ../src/lib/ecore_con/efl_net_server_unix.c:258 #9 0x7fe569e52775 in efl_net_server_fd_client_add src/lib/ecore_con/efl_net_server_fd.eo.c:137 #10 0x7fe569e4f916 in _efl_net_server_fd_process_incoming_data ../src/lib/ecore_con/efl_net_server_fd.c:481 #11 0x7fe569e5247c in efl_net_server_fd_process_incoming_data src/lib/ecore_con/efl_net_server_fd.eo.c:136 #12 0x7fe569e4d348 in _efl_net_server_fd_event_read ../src/lib/ecore_con/efl_net_server_fd.c:71 #13 0x7fe5698939b5 in _event_callback_call ../src/lib/eo/eo_base_class.c:1760 #14 0x7fe569894018 in _efl_object_event_callback_call ../src/lib/eo/eo_base_class.c:1821 #15 0x7fe56989420c in efl_event_callback_call ../src/lib/eo/eo_base_class.c:1824 #16 0x7fe56bab6a0b in _efl_loop_fd_read_cb ../src/lib/ecore/efl_loop_fd.c:34 #17 0x7fe56ba94972 in _ecore_call_fd_cb ../src/lib/ecore/ecore_private.h:519 #18 0x7fe56ba9c833 in _ecore_main_fd_handlers_call ../src/lib/ecore/ecore_main.c:2112 #19 0x7fe56ba9d78e in _ecore_main_loop_iterate_internal ../src/lib/ecore/ecore_main.c:2487 #20 0x7fe56ba97351 in _ecore_main_loop_begin ../src/lib/ecore/ecore_main.c:1199 #21 0x7fe56baab1a1 in _efl_loop_begin ../src/lib/ecore/efl_loop.c:57 #22 0x7fe56bab0560 in efl_loop_begin src/lib/ecore/efl_loop.eo.c:28 #23 0x7fe56ba9780b in ecore_main_loop_begin ../src/lib/ecore/ecore_main.c:1284 #24 0x55887ad403e1 in main ../src/bin/efreet/efreetd.c:82 #25 0x7fe56ad4ab96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) Direct leak of 100 byte(s) in 3 object(s) allocated from: #0 0x7fe56c4f9b50 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb50) #1 0x7fe563944b1e (<unknown module>) Direct leak of 24 byte(s) in 1 object(s) allocated from: #0 0x7fe56c4f9b50 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb50) #1 0x7fe563946921 (<unknown module>) Indirect leak of 2381 byte(s) in 10 object(s) allocated from: #0 0x7fe56c4f9f40 in realloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdef40) #1 0x7fe563946d6c (<unknown module>) Indirect leak of 24 byte(s) in 1 object(s) allocated from: #0 0x7fe56c4f9b50 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb50) #1 0x7fe563946921 (<unknown module>) Indirect leak of 24 byte(s) in 1 object(s) allocated from: #0 0x7fe56c4f9b50 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb50) #1 0x7fe563946985 (<unknown module>) SUMMARY: AddressSanitizer: 4249 byte(s) leaked in 36 allocation(s). The full log of moksha starting up and me triggering a crash is https://pastebin.com/4HBAWtKR. There is a little bit of noise in the boot process as clearly ASAN has revealed a few issues we need to address in moksha. Don't think it is related to the issue at hand but perhaps. For the record this is efl at commit: test@test-VirtualBox:~/Code/efl$ git show commit 3e22ac3e1c2c7828dd647480bbc81a411297cea9 (HEAD -> master, origin/master, origin/HEAD) Author: Daniel Kolesa <d.kol...@samsung.com> Date: Sat Aug 31 02:09:46 2019 +0200 eolian: always validate inner types of complex types for @move And also for the record originally moksha would not boot compiled with ASAN stuff. See https://github.com/JeffHoogland/moksha/commit/120b42e802ffa3628a5644cd2b45cf55dba6591b This is all the info I have showed Raster (except efl is more up to date with what is in git). It should also be noted that at one point I looked over e22 changes in e_icon.c as well as e_menu changes too and other uses of e_icon_preload_set in e22 and backported all that to moksha. It didn't help so it is all uncommitted in moksha, But if needed I can redo the work. Thanks for looking this over and I am hoping someone can help identify if this is an efl issue or a moksha/e17 issue and help me get this working. Peace Robert Wiley _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
