Segmentation fault when hitting key binding before progress bar starts

[SuperSandro2000]

When hitting a bound key like / before the progress bar starts crashes the application.

$ nix-tree
    <----- hit / here
[================================================================] 100/1000
Segmentation fault (core dumped)

$ coredumpctl info
           PID: 940334 (nix-tree)
           UID: 1000 (sandro)
           GID: 100 (users)
        Signal: 11 (SEGV)
     Timestamp: Wed 2023-10-11 21:07:43 CEST (10min ago)
  Command Line: nix-tree
    Executable: /nix/store/yzx1qnx565xf503d5dl8i2jaxdjmrm8k-nix-tree-0.3.1/bin/nix-tree
 Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.wezfurlong.wezterm-e1338bfae42347a4a4856fe3dfe4e330.scope
          Unit: user@1000.service
     User Unit: app-org.wezfurlong.wezterm-e1338bfae42347a4a4856fe3dfe4e330.scope
         Slice: user-1000.slice
     Owner UID: 1000 (sandro)
       Boot ID: ee11cac9e3a3481fb94c71275e6636df
    Machine ID: 8e73d0d11fdd49d7978013517a64a46f
      Hostname: magnesium
       Storage: /var/lib/systemd/coredump/core.nix-tree.1000.ee11cac9e3a3481fb94c71275e6636df.940334.1697051263000000.zst (present)
  Size on Disk: 13.1M
       Message: Process 940334 (nix-tree) of user 1000 dumped core.

                Module libffi.so.8 without build-id.
                Module libgmp.so.10 without build-id.
                Module libncursesw.so.6 without build-id.
                Module nix-tree without build-id.
                Stack trace of thread 940344:
                #0  0x00007f681a882dfe free (libc.so.6 + 0x95dfe)
                #1  0x00007f681aab61fe really_free_termtype (libncursesw.so.6 + 0x401fe)
                #2  0x00007f681aab6ad5 del_curterm_sp (libncursesw.so.6 + 0x40ad5)
                #3  0x00000000007b3ac7 n/a (nix-tree + 0x3b3ac7)
                #4  0x00000000007b3d61 n/a (nix-tree + 0x3b3d61)
                #5  0x00000000007aae1d n/a (nix-tree + 0x3aae1d)
                #6  0x00000000007ac37c n/a (nix-tree + 0x3ac37c)
                #7  0x00000000007b155c n/a (nix-tree + 0x3b155c)
                #8  0x00007f681a872dd4 start_thread (libc.so.6 + 0x85dd4)
                #9  0x00007f681a8f49b0 __clone3 (libc.so.6 + 0x1079b0)

                Stack trace of thread 940335:
                #0  0x00007f681a8e374c read (libc.so.6 + 0xf674c)
                #1  0x00000000007caaae n/a (nix-tree + 0x3caaae)
                #2  0x00007f681a872dd4 start_thread (libc.so.6 + 0x85dd4)
                #3  0x00007f681a8f49b0 __clone3 (libc.so.6 + 0x1079b0)

                Stack trace of thread 940334:
                #0  0x00000000006daeac n/a (nix-tree + 0x2daeac)
                ELF object binary architecture: AMD x86-64

[utdemir]

This seems relevant: https://github.com/jtdaugherty/brick/issues/441

[utdemir]

This is more accurate: https://github.com/jtdaugherty/vty/issues/266

It seems to be fixed with vty 5.39, however nixpkgs is still at 5.38. So I hope once the new version ends up in nixpkgs this'll be fixed.

I'll close this issue if/when that happens :).

[SuperSandro2000]

Can't we bump the dependency blind to force that update sooner?

[utdemir]

@SuperSandro2000, I am unsure - nix-tree in nixpkgs end up using the default Haskell packageset which is periodically generated from latest Stackage snapshot - I think? I can see that there's newer major versions of brick and vty on nixpkgs, but if I switch using those I'd need to add some overrides to nixpkgs definition of nix-tree, and then revert the overrides when they are actually released, which sounds like a lot of work.

BUT, I think I should ensure that nix-tree works with the newer brick version so once nixpkgs switches to it there won't be an issue.

[utdemir]

When this PR is merged to nixpkgs this should be fixed :).

[katrinafyi]

fyi, the stackage pr is merged and propagated now :) https://nixpk.gs/pr-tracker.html?pr=279413

[utdemir]

@katrinafyi , I did not know about nixpk.gs, looks super useful, thanks ❤️ !

Closing the issue, but feel free to reopen it if it still isn't fixed :).