Strange IO and segmentation fault in ghci on Macos (aarch64)

Summary

After moving the cursor left using arrow keys and pressing any keys, right part of previously inserted input duplicates. Also, window resizing causes a segmentation fault.

Steps to reproduce

1. Run ghci, press any keys, move cursor left using arrow keys, press any keys
2. Resize terminal window

Environment

• GHC version used: 8.10.5

Optional:

• Operating System: MacOS 11.4
• System Architecture: aarch64

Screen_Recording_2021-07-04_at_23.37.40

added needs triage label

cc @angerman, is this something you think will be fixed in 8.10.6?

The Segfault is helpful, that should be catchable in lldb.

I've caught it:

Executable module set to "/opt/homebrew/Cellar/ghc/8.10.5_2/lib/ghc-8.10.5/bin/ghc".
Architecture set to: arm64e-apple-macosx-.
(lldb) c
Process 14462 resuming
Process 14462 stopped
* thread #1, name = 'ghc_worker', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x5c803f0003f0034)
    frame #0: 0x000000010ac1c680 libHSbase-4.14.2.0-ghc8.10.5.dylib`base_GHCziBase_pure_info + 32
libHSbase-4.14.2.0-ghc8.10.5.dylib`base_GHCziBase_pure_info:
->  0x10ac1c680 <+32>: ldur   x22, [x23, #0xf]
    0x10ac1c684 <+36>: bl     0x10b051e40               ; symbol stub for: stg_ap_0_fast
    0x10ac1c688 <+40>: ret
    0x10ac1c68c <+44>: ldr    x9, [x23]
Target 0: (ghc) stopped.

I wonder it his happens with https://gitlab.haskell.org/ghc/ghc/-/jobs/721843/artifacts/file/ghc-arm64-apple-darwin.tar.xz as well, though I'm not 100% sure that one installs cleanly.

ghc was compiled from https://downloads.haskell.org/ghc/8.10.5/ghc-8.10.5-aarch64-apple-darwin.tar.xz with patch https://github.com/ghc/ghc/commit/296f25fa5f0fce033b529547e0658076e26f4cda.patch?full_index=1

Right, the one I linked above is a pre-release of 8.10.6, so I'm wondering if that one has the same issues, or by coincidence fixes the issues already.

I've got the same error using the pre-release artifact with the following configuration:

./configure --with-gmp-libraries=/opt/homebrew/Cellar/gmp/6.2.1/lib --with-gmp-includes=/opt/homebrew/Cellar/gmp/6.2.1/include --prefix=../ghc_bin

Ohh, that's rather annoying! Thanks for giving this a try! I'll try to get to the bottom of this, some time this week.

I appear to be able to reproduce the repeated input in ghci, however I can't reproduce the segfault with a built from master.

Ok, so one issue seems to be that we have

foreign import ccall ioctl :: FD -> CULong -> Ptr a -> IO CInt

in haskeline, however ioctl is a vargs function, and those are not supported by ccall. They just happen to work by accident for most procedure calling conventions.

SYNOPSIS
     #include <sys/ioctl.h>

     int
     ioctl(int fildes, unsigned long request, ...);

from the manpage.

but that's only used for layout computation, so I doubt it's responsible for the odd repeat/up/down issues. But might be for the segfault.

Ok. So this is fixable...

we need

-foreign import ccall tparm ::
-    CString -> CLong -> CLong -> CLong -> CLong -> CLong -> CLong
+
+foreign import capi "term.h tparm" tparm ::
+    CString -> CLong -> CLong -> CLong -> CLong -> CLong -> CLong

in terminfo as well as

-foreign import ccall ioctl :: FD -> CULong -> Ptr a -> IO CInt
+foreign import capi "sys/ioctl.h ioctl" ioctl :: FD -> CULong -> Ptr a -> IO CInt

in haskeline.

alongside with {-# language CApiFFI #-} pragmas.

our FFI simply doesn't support vargs, and without varg annotation, the codegen can never produce the proper procedure calls.

removed needs triage label

changed milestone to %8.10.6

added Phighest label

added GHCi label

added backport needed:9.2 + 1 deleted label

marked this issue as related to #20085

FYI, I've already raised an issue in haskeline:

https://github.com/judah/haskeline/issues/162

There is a workaround that I've been using and that is to invoke GHCi with:

$ TERM=dumb ghci

mentioned in merge request homepage!86 (merged)

haskeline has been bumped in %9.2.1, fixing this issue.

removed backport needed:9.2 label

haskeline submodule bumped in !6288 (merged) for %8.10.6

removed 1 deleted label