ghcup tui reliably segfaults if you hit Enter before it starts the TUI

[geekosaur]

Sadly gdb shows nothing interesting:

(gdb) run tui
Starting program: /home/allbery/.local/bin/ghcup tui
[New LWP 119322]
[New LWP 119323]
[New LWP 119324]
[New LWP 119325]
[ Info  ] downloading: https://raw.githubusercontent.com/haskell/ghcup-metadata/master/ghcup-0.0.7.yaml as file /home/allbery/.cache/ghcup/cache/ghcup-0.0.7.yaml
[Detaching after fork from child process 119326]
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
[ Info  ] downloading: https://raw.githubusercontent.com/haskell/ghcup-metadata/master/ghcup-prereleases-0.0.7.yaml as file /home/allbery/.cache/ghcup/cache/ghcup-prereleases-0.0.7.yaml
[Detaching after fork from child process 119331]
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
[New LWP 119336]

Thread 1 "ghcup" received signal SIGSEGV, Segmentation fault.
0x0000000001099c8c in ?? ()
(gdb) 
(gdb) bt
#0  0x0000000001099c8c in ?? ()
#1  0x000000000109a3d0 in ?? ()
#2  0x0000000000df0b65 in ?? ()
#3  0x0000000000000000 in ?? ()

This is ghcup 0.1.19.5 on Ubuntu 22.04.2 x86_64.

[chreekat]

Can't reproduce on the released version (0.1.19.4). I can't seem to hit Enter fast enough. :D

I tried with ghcup --metadata-caching 0 tui so I could try to have some time to catch it, but nothing works.

Running 0.1.19.4 on the haskell Docker image, which is based on Debian 10.

[geekosaur]

Actually I seem to have 0.1.19.5, and moving it out of the way and running curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org | sh again reinstalls it. Is there a new ghcup in the prerelease channel?

I also note that, while it didn't draw the TUI, it did change terminal modes (I need to stty sane to get my interrupt key back).

[chreekat]

running curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org | sh again reinstalls it.

I ran that on an empty Docker container and ended up with 0.1.19.4, which is one minor version less than what you're getting. Is it you that's on a prerelease channel somehow? :P

[geekosaur]

I am, yes (for ghc prereleases), that was why I asked about it.

[hasufell]

There's unsafe code in the TUI. We use unsafePerformIO for some state:

ghcup-hs/app/ghcup/BrickMain.hs

Line 606 in 371eda9

settings' = unsafePerformIO $ do

@geekosaur can you try the TUI rewrite at #850

[geekosaur]

app/ghcup/BrickMain.hs:66:1: error:
    Could not load module ‘Lens.Micro.TH’
    It is a member of the hidden package ‘microlens-th-0.4.3.14’.
    Perhaps you need to add ‘microlens-th’ to the build-depends in your .cabal file.
    Use -v (or `:set -v` in ghci) to see a list of the files searched for.
   |
66 | import Lens.Micro.TH (makeLenses)
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

app/ghcup/BrickMain.hs:67:1: error:
    Could not load module ‘Lens.Micro.Mtl’
    It is a member of the hidden package ‘microlens-mtl-0.2.0.3’.
    Perhaps you need to add ‘microlens-mtl’ to the build-depends in your .cabal file.
    Use -v (or `:set -v` in ghci) to see a list of the files searched for.
   |
67 | import Lens.Micro.Mtl ( (.=), use, (%=), view )
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

app/ghcup/BrickMain.hs:68:1: error:
    Could not load module ‘Lens.Micro’
    It is a member of the hidden package ‘microlens-0.4.13.1’.
    Perhaps you need to add ‘microlens’ to the build-depends in your .cabal file.
    Use -v (or `:set -v` in ghci) to see a list of the files searched for.
   |
68 | import Lens.Micro ((.~), (&))
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I notice CI didn't seem to like it either, although I have not checked to see if it had the same failures.

[geekosaur]

I switched back to master and built with ghc-options: -g. This somewhat surprisingly gets me the segfault in C code, which I would have thought would have shown in the other one unless it was being stripped.

skkukuk «ghcup-hs*master» ⁅ghcup⁆ Z$ gdb $(cabal list-bin exe:ghcup)
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /mnt/data1/ghcup-hs/dist-newstyle/build/x86_64-linux/ghc-9.2.8/ghcup-0.1.19.5/x/ghcup/build/ghcup/ghcup...
(gdb) run tui
Starting program: /mnt/data1/ghcup-hs/dist-newstyle/build/x86_64-linux/ghc-9.2.8/ghcup-0.1.19.5/x/ghcup/build/ghcup/ghcup tui
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

[New Thread 0x7ffff71ff640 (LWP 572366)]
[New Thread 0x7ffff69fe640 (LWP 572367)]
[New Thread 0x7ffff61fd640 (LWP 572368)]
[New Thread 0x7ffff59fc640 (LWP 572369)]
[New Thread 0x7ffff51fb640 (LWP 572370)]

Thread 1 "ghcup" received signal SIGSEGV, Segmentation fault.
0x00007ffff7f63743 in _nc_get_screensize () from /lib/x86_64-linux-gnu/libtinfo.so.6
(gdb) bt
#0  0x00007ffff7f63743 in _nc_get_screensize () from /lib/x86_64-linux-gnu/libtinfo.so.6
#1  0x00007ffff7f6c925 in _nc_setupterm () from /lib/x86_64-linux-gnu/libtinfo.so.6
#2  0x00000000018902bd in ?? ()
#3  0x0000000000000000 in ?? ()

I must admit I can't think of a reason why an extra Enter would cause setupterm() to segfault; this sounds like it might be an ncurses bug.

[geekosaur]

This is looking bad; the address is different every time I run it, suggesting it's C heap corruption. The most recent crash was post-setupterm, in tigetstr. ncurses 6 goes out of its way to hide its internals, so I can't tell much more.

[hasufell]

@bgamari

[geekosaur]

So we did some debugging:

• it works under rr, or at least I can't get the timing right (the double-tap that works for shell and gdb happens while rr is starting up)
• it behaves like a race condition, and moves a lot as shown in the gdb traces above
• since multithreaded calls are happening but terminfo isn't thread safe, @bgamari had me try a branch with mutexes around the terminfo calls. This changed nothing, sadly

[geekosaur]

He also had me try with the non-threaded runtime, but that just revealed that ghcup doesn't like that.

[hasufell]

I can reproduce.

I tested against #850 and it also exhibits the same issue. I'm concluding this isn't due to GHCup's code.

[hasufell]

He also had me try with the non-threaded runtime, but that just revealed that ghcup doesn't like that.

I think it's actually vty that doesn't like that (there are some forkOS calls there... ghcup itself has none). @jtdaugherty ...is it possible to use it in single threaded mode?

[jtdaugherty]

@hasufell Yeah, unfortunately, I believe this is a vty bug. It has been around for quite some time but I must admit I haven't done any investigation into it. Vty and Brick both must indeed be built with the threaded RTS, though.

[bgamari]

@jtdaugherty is there a ticket or, even better, minimal reproducer?

[jtdaugherty]

@bgamari there is now a ticket with a minimal example here: jtdaugherty/vty#266

[jtdaugherty]

A fix for this issue has been released in vty-5.39. Thanks, everyone here as well as @ShrykeWindgrace for help with testing!