On 2024-12-12 10:09:15 +0100, Yuri D'Elia wrote: > I'm getting a ~50% random crash chance during startup: [...]
I do not notice any crash when just running mlterm from 3.9.3-2, but I confirm an issue I can see with valgrind: cventin:~> valgrind mlterm ==12239== Memcheck, a memory error detector ==12239== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==12239== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info ==12239== Command: mlterm ==12239== ==12239== Invalid read of size 8 ==12239== at 0x4D41C5E: _XData32 (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0) ==12239== by 0x4D19844: XChangeProperty (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0) ==12239== by 0x11FAA7: ui_window_set_icon (ui_window.c:3202) ==12239== by 0x123BF2: set_icon (ui_screen.c:1187) ==12239== by 0x127FA4: window_realized (ui_screen.c:1349) ==12239== by 0x11D8A7: ui_window_show (ui_window.c:1480) ==12239== by 0x11D8D4: ui_window_show (ui_window.c:1502) ==12239== by 0x11BA08: ui_display_show_root (ui_display.c:383) ==12239== by 0x11A48B: open_screen_intern (ui_screen_manager.c:639) ==12239== by 0x11B30F: ui_screen_manager_startup (ui_screen_manager.c:1446) ==12239== by 0x118D8C: main_loop_start (main_loop.c:531) ==12239== by 0x117D5C: main (main.c:199) ==12239== Address 0x1fff001000 is not stack'd, malloc'd or (recently) free'd ==12239== ==12239== ==12239== HEAP SUMMARY: ==12239== in use at exit: 1,006,891 bytes in 9,945 blocks ==12239== total heap usage: 47,654 allocs, 37,709 frees, 11,408,348 bytes allocated ==12239== ==12239== LEAK SUMMARY: ==12239== definitely lost: 7,424 bytes in 28 blocks ==12239== indirectly lost: 5,931 bytes in 262 blocks ==12239== possibly lost: 912 bytes in 1 blocks ==12239== still reachable: 989,136 bytes in 9,619 blocks ==12239== suppressed: 0 bytes in 0 blocks ==12239== Rerun with --leak-check=full to see details of leaked memory ==12239== ==12239== For lists of detected and suppressed errors, rerun with: -s ==12239== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) and this terminates mlterm immediately. There is no such issue on another machine, where I still have mlterm 3.9.3-1+b3, but I get ==322436== Syscall param writev(vector[0]) points to uninitialised byte(s) ==322436== at 0x4F382E0: writev (writev.c:26) ==322436== by 0x5349015: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) ==322436== by 0x5349560: xcb_writev (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) ==322436== by 0x4D25C94: _XSend (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0) ==322436== by 0x4D260B5: _XFlush (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0) ==322436== by 0x4D0599D: XFlush (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0) ==322436== by 0x14C229: ??? (in /usr/bin/mlterm) ==322436== by 0x117D74: ??? (in /usr/bin/mlterm) ==322436== by 0x116D3C: ??? (in /usr/bin/mlterm) ==322436== by 0x4E51D67: (below main) (libc_start_call_main.h:58) ==322436== Address 0x551ec44 is 20 bytes inside a block of size 16,384 alloc'd ==322436== at 0x48489F3: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==322436== by 0x4D14CBA: XOpenDisplay (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0) ==322436== by 0x11A5D9: ??? (in /usr/bin/mlterm) ==322436== by 0x11947F: ??? (in /usr/bin/mlterm) ==322436== by 0x11A25F: ??? (in /usr/bin/mlterm) ==322436== by 0x117D5C: ??? (in /usr/bin/mlterm) ==322436== by 0x116D3C: ??? (in /usr/bin/mlterm) ==322436== by 0x4E51D67: (below main) (libc_start_call_main.h:58) (this one is not fatal, though). -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
