Crash with SIGSEGV on NixOS #2288

electria commented 2026年02月28日 17:57:09 +01:00

Foot Version

foot version: 1.25.0 +pgo +ime +graphemes -assertions

TERM environment variable

foot

Compositor Name and Version

kwin 6.6.0

Distribution

NixOS 26.05 from github:NixOS/nixpkgs/2fc6539b481e1d2569f25f8799236694180c0993

Terminal multiplexer

No response

Shell, TUI, application

fish, btop, iamb

Server/standalone mode

• Standalone
• Server

Foot config

[bell]
system=no
[main]
font=mono:size=14
include=/nix/store/s00hdn1qqw3qd3ixrsg1wg69mw122wc1-foot-1.25.0-themes/share/foot/themes/kitty
initial-window-mode=maximized

Description of Bug and Steps to Reproduce

I have the server running in the background for hours, via xdg autostart. Eventually, it suddenly spikes in memory usage (from 200MB up to 7.7GB) and crashes. I have not yet been able to find any specific cause for this yet unfortunately.

I do use fcitx5, and will try disabling it after I get some more crashes and some more information.

Relevant logs, stacktraces, etc.

Currently waiting for a crash with foot --server -d info. Will look into using a debug build on NixOS.

Attached is the output of coredumpctl info foot > coredumpctl-info-foot.txt (though I realize this isn't very useful without a debug build) and journalctl | rg "7730U foot\[" > foot-logs.txt (archived with ZSTD_CLEVEL=19 tar -cvaf foot.txt.tar.zst foot-logs.txt coredumpctl-info-foot.txt for upload efficency)

gdb bt full:

#0 0x00007fd4314cdf23 in sse2_blt.part () from /nix/store/s60msvirzaknyjgpsc8yyld1qg5i3hn5-pixman-0.46.4/lib/libpixman-1.so.0
No symbol table info available.
#1 0x00007fd4314ce1b6 in sse2_composite_copy_area () from /nix/store/s60msvirzaknyjgpsc8yyld1qg5i3hn5-pixman-0.46.4/lib/libpixman-1.so.0
No symbol table info available.
#2 0x00007fd43143b972 in pixman_image_composite32 () from /nix/store/s60msvirzaknyjgpsc8yyld1qg5i3hn5-pixman-0.46.4/lib/libpixman-1.so.0
No symbol table info available.
#3 0x000056088764dce1 in render_worker_thread ()
No symbol table info available.
#4 0x00007fd43109dbe3 in start_thread (arg=<optimized out>) at pthread_create.c:445
 start = <optimized out>
 ret = <optimized out>
 pd = <optimized out>
 out = <optimized out>
 unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140540322510528, -5139950223209593563, 140540322510528, 140723307956496, 11, 140723307956759, -5139950223184427739, 
 -5141009138455870171}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
 not_first_call = <optimized out>
#5 0x00007fd43112563c in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

### Foot Version foot version: 1.25.0 +pgo +ime +graphemes -assertions ### TERM environment variable foot ### Compositor Name and Version kwin 6.6.0 ### Distribution NixOS 26.05 from github:NixOS/nixpkgs/2fc6539b481e1d2569f25f8799236694180c0993 ### Terminal multiplexer _No response_ ### Shell, TUI, application fish, btop, iamb ### Server/standalone mode - [ ] Standalone - [x] Server ### Foot config ```ini [bell] system=no [main] font=mono:size=14 include=/nix/store/s00hdn1qqw3qd3ixrsg1wg69mw122wc1-foot-1.25.0-themes/share/foot/themes/kitty initial-window-mode=maximized ``` ### Description of Bug and Steps to Reproduce I have the server running in the background for hours, via xdg autostart. Eventually, it suddenly spikes in memory usage (from 200MB up to 7.7GB) and crashes. I have not yet been able to find any specific cause for this yet unfortunately. I do use fcitx5, and will try disabling it after I get some more crashes and some more information. ### Relevant logs, stacktraces, etc. Currently waiting for a crash with `foot --server -d info`. Will look into using a debug build on NixOS. Attached is the output of `coredumpctl info foot > coredumpctl-info-foot.txt` (though I realize this isn't very useful without a debug build) and `journalctl | rg "7730U foot\[" > foot-logs.txt` (archived with `ZSTD_CLEVEL=19 tar -cvaf foot.txt.tar.zst foot-logs.txt coredumpctl-info-foot.txt` for upload efficency) gdb `bt full`: ``` #0 0x00007fd4314cdf23 in sse2_blt.part () from /nix/store/s60msvirzaknyjgpsc8yyld1qg5i3hn5-pixman-0.46.4/lib/libpixman-1.so.0 No symbol table info available. #1 0x00007fd4314ce1b6 in sse2_composite_copy_area () from /nix/store/s60msvirzaknyjgpsc8yyld1qg5i3hn5-pixman-0.46.4/lib/libpixman-1.so.0 No symbol table info available. #2 0x00007fd43143b972 in pixman_image_composite32 () from /nix/store/s60msvirzaknyjgpsc8yyld1qg5i3hn5-pixman-0.46.4/lib/libpixman-1.so.0 No symbol table info available. #3 0x000056088764dce1 in render_worker_thread () No symbol table info available. #4 0x00007fd43109dbe3 in start_thread (arg=<optimized out>) at pthread_create.c:445 start = <optimized out> ret = <optimized out> pd = <optimized out> out = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140540322510528, -5139950223209593563, 140540322510528, 140723307956496, 11, 140723307956759, -5139950223184427739, -5141009138455870171}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> #5 0x00007fd43112563c in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 ```

dnkl commented 2026年03月02日 07:51:49 +01:00

Might be a duplicate of #2263

_Might_ be a duplicate of https://codeberg.org/dnkl/foot/issues/2263

electria commented 2026年03月02日 15:43:44 +01:00

Might be a duplicate of #2263

This is actually likely, my version of foot does not have the commit that fixed this issue. Sorry, neglected to search closed issues.

I will update foot and and see if the issue persists.

> _Might_ be a duplicate of #2263 This is actually likely, my version of foot does not have the commit that fixed this issue. Sorry, neglected to search closed issues. I will update foot and and see if the issue persists.

electria commented 2026年03月03日 17:11:19 +01:00

Thank you! That seems to have fixed it.

In case anyone also using NixOS runs into this before this fix gets into a release, here's something you can copy, since compiling foot isn't very intensive:

programs.foot.package = pkgs.foot.overrideAttrs {
 src = pkgs.fetchFromCodeberg {
 owner = "dnkl";
 repo = "foot";
 rev = "046898f1b8";
 hash = "sha256-jGoc/4f8YA/w8x3g8La+2vEnsOoW+5ZtzX6fkZk2Dxk=";
 };
};

This causes a deprication error, but that's nixpkgs' fault because the module was unintentionally made to pull the themes from a hardcoded foot package, and that will be solved by https://github.com/NixOS/nixpkgs/pull/493708;

And thank you for this great terminal emulator dnkl :)

Thank you! That seems to have fixed it. In case anyone also using NixOS runs into this before this fix gets into a release, here's something you can copy, since compiling foot isn't very intensive: ```nix programs.foot.package = pkgs.foot.overrideAttrs { src = pkgs.fetchFromCodeberg { owner = "dnkl"; repo = "foot"; rev = "046898f1b8"; hash = "sha256-jGoc/4f8YA/w8x3g8La+2vEnsOoW+5ZtzX6fkZk2Dxk="; }; }; ``` This causes a deprication error, but that's nixpkgs' fault because the module was unintentionally made to pull the themes from a hardcoded foot package, and that will be solved by https://github.com/NixOS/nixpkgs/pull/493708; And thank you for this great terminal emulator dnkl :)

electria commented 2026年03月04日 03:34:13 +01:00

I may have been too hasty to close this issue; it's crashed again in the same circumstances. (revision 046898f1b8, foot version: 1.25.0 +pgo +ime +graphemes +toplevel-tag +blur -assertions)

I may have been too hasty to close this issue; it's crashed again in the same circumstances. (revision 046898f1b8, `foot version: 1.25.0 +pgo +ime +graphemes +toplevel-tag +blur -assertions`)

dnkl commented 2026年03月05日 16:23:08 +01:00

Please try to get a backtrace from a debug build of the latest 1.26.0 release.

Please try to get a backtrace from a debug build of the latest 1.26.0 release.

electria commented 2026年03月05日 18:12:03 +01:00

Please try to get a backtrace from a debug build of the latest 1.26.0 release.

Yep, waiting for a crash with: foot version: 1.26.0 -pgo +ime +graphemes +toplevel-tag +blur +assertions

built with:

programs.foot.package =
 (pkgs.foot.overrideAttrs {
 src = pkgs.fetchFromCodeberg {
 owner = "dnkl";
 repo = "foot";
 tag = "1.26.0";
 hash = "sha256-XnGNrQVdSyg5CVBZBwrqDPbf4/+9yyerGBrZArbh6xI=";
 };
 mesonBuildType = "debug";
 env.CFLAGS = ""; # this overrides "-O3"
 }).override
 {
 allowPgo = false;
 };
environment.enableDebugInfo = true;

> Please try to get a backtrace from a debug build of the latest 1.26.0 release. Yep, waiting for a crash with: `foot version: 1.26.0 -pgo +ime +graphemes +toplevel-tag +blur +assertions` built with: ```nix programs.foot.package = (pkgs.foot.overrideAttrs { src = pkgs.fetchFromCodeberg { owner = "dnkl"; repo = "foot"; tag = "1.26.0"; hash = "sha256-XnGNrQVdSyg5CVBZBwrqDPbf4/+9yyerGBrZArbh6xI="; }; mesonBuildType = "debug"; env.CFLAGS = ""; # this overrides "-O3" }).override { allowPgo = false; }; environment.enableDebugInfo = true; ```

electria commented 2026年03月06日 17:59:59 +01:00

@dnkl I got it but this doesn't look very helpful...

Using host libthread_db library "/nix/store/l0l2ll1lmylczj1ihqn351af2kyp5x19-glibc-2.42-51/lib/libthread_db.so.1".
Core was generated by `/run/current-system/sw/bin/foot --server'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f30e3b51f1b in sse2_blt.part () from /nix/store/s60msvirzaknyjgpsc8yyld1qg5i3hn5-pixman-0.46.4/lib/libpixman-1.so.0
[Current thread is 1 (Thread 0x7f3008ff96c0 (LWP 14260))]
(gdb) bt full
#0 0x00007f30e3b51f1b in sse2_blt.part () from /nix/store/s60msvirzaknyjgpsc8yyld1qg5i3hn5-pixman-0.46.4/lib/libpixman-1.so.0
No symbol table info available.
#1 0x00007f30e3b521b6 in sse2_composite_copy_area ()
 from /nix/store/s60msvirzaknyjgpsc8yyld1qg5i3hn5-pixman-0.46.4/lib/libpixman-1.so.0
No symbol table info available.
#2 0x00007f30e3abf972 in pixman_image_composite32 ()
 from /nix/store/s60msvirzaknyjgpsc8yyld1qg5i3hn5-pixman-0.46.4/lib/libpixman-1.so.0
No symbol table info available.
#3 0x000055e59316d117 in render_worker_thread ()
No symbol table info available.
#4 0x00007f30e369dbe3 in start_thread (arg=<optimized out>) at pthread_create.c:445
 start = <optimized out>
 ret = <optimized out>
 pd = <optimized out>
 out = <optimized out>
 unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139844286125760, -3129067261022328172, 139844286125760, 140730252097440, 11, 
 140730252097703, -3129067260997162348, -3129290583670019436}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, 
 data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
 not_first_call = <optimized out>
#5 0x00007f30e372563c in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
No locals.

Does this mean it's a bug within pixman ?

@dnkl I got it but this doesn't look very helpful... ``` Using host libthread_db library "/nix/store/l0l2ll1lmylczj1ihqn351af2kyp5x19-glibc-2.42-51/lib/libthread_db.so.1". Core was generated by `/run/current-system/sw/bin/foot --server'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f30e3b51f1b in sse2_blt.part () from /nix/store/s60msvirzaknyjgpsc8yyld1qg5i3hn5-pixman-0.46.4/lib/libpixman-1.so.0 [Current thread is 1 (Thread 0x7f3008ff96c0 (LWP 14260))] (gdb) bt full #0 0x00007f30e3b51f1b in sse2_blt.part () from /nix/store/s60msvirzaknyjgpsc8yyld1qg5i3hn5-pixman-0.46.4/lib/libpixman-1.so.0 No symbol table info available. #1 0x00007f30e3b521b6 in sse2_composite_copy_area () from /nix/store/s60msvirzaknyjgpsc8yyld1qg5i3hn5-pixman-0.46.4/lib/libpixman-1.so.0 No symbol table info available. #2 0x00007f30e3abf972 in pixman_image_composite32 () from /nix/store/s60msvirzaknyjgpsc8yyld1qg5i3hn5-pixman-0.46.4/lib/libpixman-1.so.0 No symbol table info available. #3 0x000055e59316d117 in render_worker_thread () No symbol table info available. #4 0x00007f30e369dbe3 in start_thread (arg=<optimized out>) at pthread_create.c:445 start = <optimized out> ret = <optimized out> pd = <optimized out> out = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139844286125760, -3129067261022328172, 139844286125760, 140730252097440, 11, 140730252097703, -3129067260997162348, -3129290583670019436}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> #5 0x00007f30e372563c in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 No locals. ``` Does this mean it's a bug within `pixman` ?

electria commented 2026年03月07日 16:54:32 +01:00

I was able to get some more debug info as it crashed today:

#0 0x00007fcb144f80be in _mm_store_si128 (__P=0x7fca3bc7d000, __B=...)
 at /nix/store/sca0pf46jmxva40qahkcwys5c1lvk6n2-gcc-15.2.0/lib/gcc/x86_64-unknown-linux-gnu/15.2.0/include/emmintrin.h:737
No locals.
#1 save_128_aligned (dst=0x7fca3bc7d000, data=...) at ../pixman/pixman-sse2.c:381
No locals.
#2 sse2_blt (imp=0x5611bfe17d20, src_bits=0x7fca031c8000, dst_bits=0x7fca3b2e0000, src_stride=10240, dst_stride=10240, src_bpp=32, dst_bpp=32, src_x=0, src_y=0, dest_x=0, 
 dest_y=0, width=2560, height=398) at ../pixman/pixman-sse2.c:4757
 xmm0 = {-72057589759737856, -72057589759737856}
 xmm1 = {-72057589759737856, -72057589759737856}
 xmm2 = {-72057589759737856, -72057589759737856}
 xmm3 = {-72057589759737856, -72057589759737856}
 w = 6144
 s = 0x7fca03b65000 ""
 d = 0x7fca3bc7d000 <error: Cannot access memory at address 0x7fca3bc7d000>
 src_bytes = 0x7fca03b66800 ""
 dst_bytes = 0x7fca3bc7e800 <error: Cannot access memory at address 0x7fca3bc7e800>
 byte_width = 10240
#3 0x00007fcb144f8410 in sse2_composite_copy_area (imp=0x5611bfe17d20, info=0x7fcaca7fbb40) at ../pixman/pixman-sse2.c:4802
 op = PIXMAN_OP_SRC
 src_image = 0x5611bfee2f30
 mask_image = 0x0
 dest_image = 0x5611c03f5980
 src_x = 0
 src_y = 0
 mask_x = 0
 mask_y = 0
 dest_x = 0
 dest_y = 0
 width = 2560
 height = 1383
#4 0x00007fcb1420d999 in pixman_image_composite32 (op=PIXMAN_OP_SRC, src=0x5611bfee2f30, mask=0x0, dest=0x5611c03f5980, src_x=0, src_y=0, mask_x=0, mask_y=0, dest_x=0, dest_y=0, 
 width=2560, height=1383) at ../pixman/pixman.c:715
 src_format = PIXMAN_a8r8g8b8
 mask_format = 0
 dest_format = PIXMAN_a8r8g8b8
 region = {extents = {x1 = 0, y1 = 0, x2 = 2560, y2 = 1383}, data = 0x0}
 extents = {x1 = 0, y1 = 0, x2 = 2560, y2 = 1383}
 imp = 0x5611bfe17d20
 func = 0x7fcb144f82db <sse2_composite_copy_area>
 info = {op = PIXMAN_OP_SRC, src_image = 0x5611bfee2f30, mask_image = 0x0, dest_image = 0x5611c03f5980, src_x = 0, src_y = 0, mask_x = 0, mask_y = 0, dest_x = 0, dest_y = 0, 
 width = 2560, height = 1383, src_flags = 42420863, mask_flags = 8194, dest_flags = 34032255}
 pbox = 0x7fcaca7fbb20
 n = 0
#5 0x00005611a6e9e03c in render_worker_thread (_ctx=0x5611bff649e0) at ../render.c:2257
 dmg = {extents = {x1 = 0, y1 = 0, x2 = 2560, y2 = 1383}, data = 0x0}
 row_no = -3
 buf = 0x7fca880464e0
 frame_done = false
 cursor = {col = 0, row = 48}
 ctx = 0x5611bff649e0
 term = 0x5611bff88550
 my_id = 5
 mask = {__val = {18446744067267100671, 3480328324138074368, 140508957490368, 140510189740543, 0, 140508949102592, 11, 140722027361271, 140508957490464, 140510189181427, 0, 
 140508957490400, 2322277832189568800, 2334097595223798896, 3756066322130236531, 3289400}}
 proc_title = "foot:render:5000円L0"
 start = 0x5611bff89508
 done = 0x5611bff89528
 lock = 0x5611bff89548
 __func__ = "render_worker_thread"
 __PRETTY_FUNCTION__ = "render_worker_thread"
#6 0x00007fcb13e9dbe3 in start_thread (arg=<optimized out>) at pthread_create.c:445
 start = <optimized out>
 ret = <optimized out>
 pd = <optimized out>
 out = <optimized out>
 unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140508957492928, -5493835322888711253, 140508957492928, 140722027361008, 11, 140722027361271, -5493835322880322645, 
 -5493746349338553429}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
 not_first_call = <optimized out>
#7 0x00007fcb13f2563c in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
No locals.

I was able to get some more debug info as it crashed today: ``` #0 0x00007fcb144f80be in _mm_store_si128 (__P=0x7fca3bc7d000, __B=...) at /nix/store/sca0pf46jmxva40qahkcwys5c1lvk6n2-gcc-15.2.0/lib/gcc/x86_64-unknown-linux-gnu/15.2.0/include/emmintrin.h:737 No locals. #1 save_128_aligned (dst=0x7fca3bc7d000, data=...) at ../pixman/pixman-sse2.c:381 No locals. #2 sse2_blt (imp=0x5611bfe17d20, src_bits=0x7fca031c8000, dst_bits=0x7fca3b2e0000, src_stride=10240, dst_stride=10240, src_bpp=32, dst_bpp=32, src_x=0, src_y=0, dest_x=0, dest_y=0, width=2560, height=398) at ../pixman/pixman-sse2.c:4757 xmm0 = {-72057589759737856, -72057589759737856} xmm1 = {-72057589759737856, -72057589759737856} xmm2 = {-72057589759737856, -72057589759737856} xmm3 = {-72057589759737856, -72057589759737856} w = 6144 s = 0x7fca03b65000 "" d = 0x7fca3bc7d000 <error: Cannot access memory at address 0x7fca3bc7d000> src_bytes = 0x7fca03b66800 "" dst_bytes = 0x7fca3bc7e800 <error: Cannot access memory at address 0x7fca3bc7e800> byte_width = 10240 #3 0x00007fcb144f8410 in sse2_composite_copy_area (imp=0x5611bfe17d20, info=0x7fcaca7fbb40) at ../pixman/pixman-sse2.c:4802 op = PIXMAN_OP_SRC src_image = 0x5611bfee2f30 mask_image = 0x0 dest_image = 0x5611c03f5980 src_x = 0 src_y = 0 mask_x = 0 mask_y = 0 dest_x = 0 dest_y = 0 width = 2560 height = 1383 #4 0x00007fcb1420d999 in pixman_image_composite32 (op=PIXMAN_OP_SRC, src=0x5611bfee2f30, mask=0x0, dest=0x5611c03f5980, src_x=0, src_y=0, mask_x=0, mask_y=0, dest_x=0, dest_y=0, width=2560, height=1383) at ../pixman/pixman.c:715 src_format = PIXMAN_a8r8g8b8 mask_format = 0 dest_format = PIXMAN_a8r8g8b8 region = {extents = {x1 = 0, y1 = 0, x2 = 2560, y2 = 1383}, data = 0x0} extents = {x1 = 0, y1 = 0, x2 = 2560, y2 = 1383} imp = 0x5611bfe17d20 func = 0x7fcb144f82db <sse2_composite_copy_area> info = {op = PIXMAN_OP_SRC, src_image = 0x5611bfee2f30, mask_image = 0x0, dest_image = 0x5611c03f5980, src_x = 0, src_y = 0, mask_x = 0, mask_y = 0, dest_x = 0, dest_y = 0, width = 2560, height = 1383, src_flags = 42420863, mask_flags = 8194, dest_flags = 34032255} pbox = 0x7fcaca7fbb20 n = 0 #5 0x00005611a6e9e03c in render_worker_thread (_ctx=0x5611bff649e0) at ../render.c:2257 dmg = {extents = {x1 = 0, y1 = 0, x2 = 2560, y2 = 1383}, data = 0x0} row_no = -3 buf = 0x7fca880464e0 frame_done = false cursor = {col = 0, row = 48} ctx = 0x5611bff649e0 term = 0x5611bff88550 my_id = 5 mask = {__val = {18446744067267100671, 3480328324138074368, 140508957490368, 140510189740543, 0, 140508949102592, 11, 140722027361271, 140508957490464, 140510189181427, 0, 140508957490400, 2322277832189568800, 2334097595223798896, 3756066322130236531, 3289400}} proc_title = "foot:render:5000円L0" start = 0x5611bff89508 done = 0x5611bff89528 lock = 0x5611bff89548 __func__ = "render_worker_thread" __PRETTY_FUNCTION__ = "render_worker_thread" #6 0x00007fcb13e9dbe3 in start_thread (arg=<optimized out>) at pthread_create.c:445 start = <optimized out> ret = <optimized out> pd = <optimized out> out = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140508957492928, -5493835322888711253, 140508957492928, 140722027361008, 11, 140722027361271, -5493835322880322645, -5493746349338553429}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> #7 0x00007fcb13f2563c in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 No locals. ```

dnkl commented 2026年03月09日 19:01:15 +01:00

Thanks, this tells is it is very much related to #2263. However, I need to know what all the other threads are doing at the time of the crash. Can you run thread apply all bt full (if I remember correctly...) when you get the crash (or on the same core dump as above, if you still have it).

Thanks, this tells is it _is_ very much related to https://codeberg.org/dnkl/foot/issues/2263. However, I need to know what all the _other_ threads are doing at the time of the crash. Can you run `thread apply all bt full` (if I remember correctly...) when you get the crash (or on the same core dump as above, if you still have it).

electria commented 2026年03月09日 19:11:14 +01:00

I have all coredumps, they're managed by systemd and I don't clear them.
Attached is echo thread apply all bt full | coredumpctl debug 2303 > all_threads_backtrace.txt and I think it's the same coredump as the previous one I posted.

I have all coredumps, they're managed by systemd and I don't clear them. Attached is `echo thread apply all bt full | coredumpctl debug 2303 > all_threads_backtrace.txt` and I *think* it's the same coredump as the previous one I posted.

dnkl commented 2026年03月10日 07:53:06 +01:00

Thanks, please test #2297

Thanks, please test https://codeberg.org/dnkl/foot/pulls/2297

electria commented 2026年03月10日 19:37:04 +01:00

Thanks, please test #2297

currently testing:

programs.foot.package =
 (pkgs.foot.override {
 allowPgo = false;
 }).overrideAttrs
 (
 finalAttrs: previousAttrs: {
 src = pkgs.fetchFromCodeberg {
 owner = "dnkl";
 repo = "foot";
 rev = "657db18a4ec4df93689c3eaae03b70f851724001";
 hash = "sha256-oYAGurUhXr7NumtetWiFtQXQGT7mzLHeyMQAVmjvup0=";
 };
 mesonBuildType = "debug";
 mesonFlags = lib.remove "-Db_lto=true" previousAttrs.mesonFlags;
 env.CFLAGS = ""; # this overrides "-O3"
 }
 );

no crashes thus far!

I'll give it a few days and then close this if all goes well.

> Thanks, please test #2297 currently testing: ```nix programs.foot.package = (pkgs.foot.override { allowPgo = false; }).overrideAttrs ( finalAttrs: previousAttrs: { src = pkgs.fetchFromCodeberg { owner = "dnkl"; repo = "foot"; rev = "657db18a4ec4df93689c3eaae03b70f851724001"; hash = "sha256-oYAGurUhXr7NumtetWiFtQXQGT7mzLHeyMQAVmjvup0="; }; mesonBuildType = "debug"; mesonFlags = lib.remove "-Db_lto=true" previousAttrs.mesonFlags; env.CFLAGS = ""; # this overrides "-O3" } ); ``` no crashes thus far! I'll give it a few days and then close this if all goes well.

dnkl commented 2026年03月12日 13:29:33 +01:00

Btw, you might want to add -O0 -ggdb (and make sure the binary isn't stripped). That might explain why we're not seeing proper symbols and line numbers.

Btw, you might want to add `-O0 -ggdb` (and make sure the binary isn't stripped). That might explain why we're not seeing proper symbols and line numbers.

dnkl commented 2026年03月12日 13:30:15 +01:00

Or maybe those are added by mesonBuildType = "debug". Anyway, make sure the debug info isn't stripped from the binary.

Or maybe those are added by `mesonBuildType = "debug"`. Anyway, make sure the debug info isn't stripped from the binary.

electria commented 2026年03月12日 16:42:58 +01:00

Btw, you might want to add -O0 -ggdb (and make sure the binary isn't stripped). That might explain why we're not seeing proper symbols and line numbers.

In NixOS the debug symbols are packaged separately. It looks to me like there are proper symbols and line numbers in what I posted here though?
For instance (taken from all_threads_backtrace.txt):

#8 0x00005611a6e92390 in main (argc=0, argv=0x7ffc66742158) at ../main.c:676
 foot_exit_failure = -26
 ret = 0
 token = 0x0
 prog_name = 0x7ffc667434f0 "/run/current-system/sw/bin/foot"
(shortened for brevity)

This points to where the main thread excecutes fdm_poll() in a loop which makes sense to me.

> Btw, you might want to add `-O0 -ggdb` (and make sure the binary isn't stripped). That might explain why we're not seeing proper symbols and line numbers. In NixOS the debug symbols are packaged separately. It looks to me like there are proper symbols and line numbers in what I posted here though? For instance (taken from [`all_threads_backtrace.txt`](https://codeberg.org/dnkl/foot/issues/2288#issuecomment-11427526)): ``` #8 0x00005611a6e92390 in main (argc=0, argv=0x7ffc66742158) at ../main.c:676 foot_exit_failure = -26 ret = 0 token = 0x0 prog_name = 0x7ffc667434f0 "/run/current-system/sw/bin/foot" (shortened for brevity) ``` This points to where the main thread excecutes `fdm_poll()` in a loop which makes sense to me.

electria commented 2026年03月12日 16:44:51 +01:00

In any case, I've had no further crashes so I believe you solved the problem. Thanks again!

In any case, I've had no further crashes so I believe you solved the problem. Thanks again!

dnkl commented 2026年03月12日 16:50:46 +01:00

For instance (taken from all_threads_backtrace.txt):

You're right! I only looked at the top of the file, not the actual gdb backtrace. There we have:

 #4 0x00005611a6eb4cfb shm_purge (/nix/store/k2cxq8wgl90m2yliz362nbps218lwna1-foot-1.26.0/bin/foot + 0x67cfb)
 #5 0x00005611a6ec4220 wayl_win_destroy (/nix/store/k2cxq8wgl90m2yliz362nbps218lwna1-foot-1.26.0/bin/foot + 0x77220)
 #6 0x00005611a6ed9fd8 fdm_shutdown (/nix/store/k2cxq8wgl90m2yliz362nbps218lwna1-foot-1.26.0/bin/foot + 0x8cfd8)
 #7 0x00005611a6e7ffbd fdm_poll (/nix/store/k2cxq8wgl90m2yliz362nbps218lwna1-foot-1.26.0/bin/foot + 0x32fbd)
 #8 0x00005611a6e92390 main (/nix/store/k2cxq8wgl90m2yliz362nbps218lwna1-foot-1.26.0/bin/foot + 0x45390)
 #9 0x00007fcb13e2b285 __libc_start_call_main (libc.so.6 + 0x2b285)
 #10 0x00007fcb13e2b338 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2b338)
 #11 0x00005611a6e63315 _start (/nix/store/k2cxq8wgl90m2yliz362nbps218lwna1-foot-1.26.0/bin/foot + 0x16315)

This was good enough, so I didn't even bother looking at the rest of the file...

In any case, I've had no further crashes so I believe you solved the problem. Thanks again!

Alright, I'll merge the PR, and try to do a patch release soonish

> For instance (taken from all_threads_backtrace.txt): You're right! I only looked at the top of the file, not the actual gdb backtrace. There we have: ``` #4 0x00005611a6eb4cfb shm_purge (/nix/store/k2cxq8wgl90m2yliz362nbps218lwna1-foot-1.26.0/bin/foot + 0x67cfb) #5 0x00005611a6ec4220 wayl_win_destroy (/nix/store/k2cxq8wgl90m2yliz362nbps218lwna1-foot-1.26.0/bin/foot + 0x77220) #6 0x00005611a6ed9fd8 fdm_shutdown (/nix/store/k2cxq8wgl90m2yliz362nbps218lwna1-foot-1.26.0/bin/foot + 0x8cfd8) #7 0x00005611a6e7ffbd fdm_poll (/nix/store/k2cxq8wgl90m2yliz362nbps218lwna1-foot-1.26.0/bin/foot + 0x32fbd) #8 0x00005611a6e92390 main (/nix/store/k2cxq8wgl90m2yliz362nbps218lwna1-foot-1.26.0/bin/foot + 0x45390) #9 0x00007fcb13e2b285 __libc_start_call_main (libc.so.6 + 0x2b285) #10 0x00007fcb13e2b338 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2b338) #11 0x00005611a6e63315 _start (/nix/store/k2cxq8wgl90m2yliz362nbps218lwna1-foot-1.26.0/bin/foot + 0x16315) ``` This was good enough, so I didn't even bother looking at the rest of the file... > In any case, I've had no further crashes so I believe you solved the problem. Thanks again! Alright, I'll merge the PR, and try to do a patch release soonish

electria commented 2026年03月12日 16:56:44 +01:00

You're right! I only looked at the top of the file, not the actual gdb backtrace.

Oh, those are just systemd logs.
Would it have been better if I trimmed those out?

Alright, I'll merge the PR, and try to do a patch release soonish

❤️

> You're right! I only looked at the top of the file, not the actual gdb backtrace. Oh, those are just systemd logs. Would it have been better if I trimmed those out? > Alright, I'll merge the PR, and try to do a patch release soonish ❤️

dnkl commented 2026年03月12日 17:04:34 +01:00

Oh, those are just systemd logs.

Yeah, I figured. My fault :)

Would it have been better if I trimmed those out?

Nah, it's my fault. Now I know. And, if I had needed it, I would probably have scrolled through the entire text file and found the actual back trace. All is good :)

> Oh, those are just systemd logs. Yeah, I figured. My fault :) > Would it have been better if I trimmed those out? Nah, it's my fault. Now I know. And, if I had needed it, I would probably have scrolled through the entire text file and found the actual back trace. All is good :)