Segmentation Fault when running stack in zsh (MacOS)

[mky2]

Summary

When using stack in zsh it returns segfault.

Steps to reproduce

Using zsh to run:

brew install stack
stack new project

But if you add the verbose flag, or redirect its stdout, it does not segfault.

stack new project -v
stack new project2 > /dev/null

run perfectly fine.
Note that not all commands fail, for example

stack --help
stack config

work.
If one uses bash instead of zsh, it also runs without any problem.

Version

OS: MacOS 11.5.2 aarch64
Zsh: 5.8
Terminal: The MacOS builtin terminal
Installation method: homebrew

$ stack --version
Version 2.7.3 aarch64

[mattaudesse]

@paqg it looks like you're using an M1 Mac but I don't think stack fully supports those yet.

[jgm]

I've experienced this too. M1 mac, haskell-stack installed via homebrew -- works fine on bash, segfaults on zsh.
Oddly, most of my stack usage is okay, but certain things segfault (stack upload for one).
(I can also confirm that redirecting stdout solves the problem even on zsh.)

[massung]

I'd like to note that I get the segmentation faults as well, but I do not get them when using zsh on iTerm2. I do get them using the default Terminal.app, Alacrity and WezTerm, though.

Can anyone else confirm this is the case for them as well? I'm not sure what's different running zsh from a different terminal.

[Meowcolm024]

stack build directly via cabal also have the same problem.
stack repl/build/update does not work on the default terminal, but work on iTerm2 :(

[fwcd]

I am having the same issue, running on an Apple Silicon Mac, stack build segfaults when running from zsh (both the built-in zsh and Homebrew-installed zsh), but not from other shells. Debugging the invocation with lldb -- /opt/homebrew/bin/zsh -c "stack build" yields the following backtrace:

(lldb) run
Process 834 launched: '/opt/homebrew/bin/zsh' (arm64)
Process 834 stopped
* thread #2, stop reason = exec
    frame #0: 0x000000010a80c5d0 dyld`_dyld_start
dyld`_dyld_start:
->  0x10a80c5d0 <+0>:  mov    x0, sp
    0x10a80c5d4 <+4>:  and    sp, x0, #0xfffffffffffffff0
    0x10a80c5d8 <+8>:  mov    x29, #0x0
    0x10a80c5dc <+12>: mov    x30, #0x0
Target 0: (stack) stopped.

[fwcd]

As a workaround I have created a small wrapper script that runs in Bash and passes its arguments along to stack along with the LLVM paths that GHC 8.10 currently needs, but this is of course far from ideal:

#!/bin/bash

export PATH="/opt/homebrew/opt/llvm@12/bin:$PATH"
export LDFLAGS="-L/opt/homebrew/opt/llvm@12/lib"
export CPPFLAGS="-I/opt/homebrew/opt/llvm@12/include"

/opt/homebrew/bin/stack "$@"

[jgm]

I would suggest changing the last line in @fwcd's script to

/opt/homebrew/bin/stack "$@"

so quoted parameters work properly.

[fwcd]

Updated, thanks!

[plajjan]

I've encountered stack segfaulting on M1 too. It doesn't appear to be limited to when running under zsh. I've tried changing my shell to bash and when I log in via ssh and attempt to use stack build I get a segfault:

mini:compiler kll$ echo $SHELL
/bin/bash
mini:compiler kll$ stack build
Segmentation fault: 11
mini:compiler kll$ 

Using stack in iTerm2 works just fine with zsh. Not sure how to debug further!?

[geraldus]

Having similar issue when running stack from fish or zsh, albeit running from bash works.

System Version: macOS 12.0.1 (21A559)
Kernel Version: Darwin 21.1.0

Tried stack versions:

• Version 2.7.3 aarch64, Homebrew
• Version 2.7.4 RELEASE-CANDIDATE aarch64, Homebrew, HEAD

zsh

% stack ghci
zsh: segmentation fault stack ghci

fish

> stack ghci
fish: Job 1, 'stack ghci' terminated by signal SIGSEGV (Address boundary error)

bash

> bash -c 'stack ghci'

Note: No local targets specified, so a
plain ghci will be started with no
package hiding or package options.

  You are using snapshot: lts-18.13
  
  If you want to use package hiding
  and options, then you can try one
  of the following:
  
  * If you want to start a different
    project configuration
    than /Users/arthurfayzrakhmanov/.stack/global-project/stack.yaml, then you can use
    stack init to create a new
    stack.yaml for the packages in
    the current directory. 
    
  * If you want to use the project
    configuration
    at /Users/arthurfayzrakhmanov/.stack/global-project/stack.yaml, then you can add to its 'packages' field.

Configuring GHCi with the following packages:
GHCi, version 8.10.7: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /private/var/folders/2w/mhv9mt797jj6qrsmbc4yv3540000gn/T/haskell-stack-ghci/2a3bbd58/ghci-script
Prelude>

Update: if I sub-shell to fish again, it works too. I suppose this is an environment configuration issue

arthurfayzrakhmanov@MBP-Arthur ~> stack ghci
fish: Job 1, 'stack ghci' terminated by signal SIGSEGV (Address boundary error)
arthurfayzrakhmanov@MBP-Arthur ~ [SIGSEGV]> fish
Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
arthurfayzrakhmanov@MBP-Arthur ~> stack ghci

Note: No local targets specified, so a plain ghci will be started with no package hiding or package options.
      
      You are using snapshot: lts-18.13
      
      If you want to use package hiding and options, then you can try one of the following:
      
      * If you want to start a different project configuration than /Users/arthurfayzrakhmanov/.stack/global-project/stack.yaml, then you can use stack init to create a new stack.yaml for the packages
        in the current directory. 
        
      * If you want to use the project configuration at /Users/arthurfayzrakhmanov/.stack/global-project/stack.yaml, then you can add to its 'packages' field.
      
Configuring GHCi with the following packages: 
GHCi, version 8.10.7: https://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /private/var/folders/2w/mhv9mt797jj6qrsmbc4yv3540000gn/T/haskell-stack-ghci/2a3bbd58/ghci-script
Prelude> 

[dixonary]

I can confirm that across around 10 M1 macs that I helped to configure for students, each with the same or similar configuration, the same error is present, and with the same symptoms - no crash in bash, no crash when piping output to /dev/null.

In my own case, stack was working perfectly up until today, where the same segmentation fault started to occur with no changes to configuration on my part.

Edit: with regards the comment below, I use iterm2 and vscode, and the error started popping up in both at the same time yesterday and has not gone away.

[larancibia]

I have the same issue when I use the Intellij IDE terminal. But on Iterm2 everything works fine.

On the other hand on the Intellij terminal (/bin/zsh) It's like "The Bug of Schrodinger" because when I use the --verbose flag to find the origin of the problem, the issue disappears. And when I am not using the --verbose flag, I have the segmentation fault.

But when I use a --verbose flag works fine surprisingly

[sethetter]

@larancibia so interesting! Adding the --verbose flag worked for me as well on the stack new command. How strange!

Edit: Using bash did not work for me.

[pradipgharge]

I am having the same issue while running stack setup leads to a segmentation fault, what can I do to fix this?

[eugene-milostivenko]

The only way to make stack work stably on M1 macs is to use brew x86_64 under rosetta. In my case, the aarch64 version was unusable. Are there any ETAs for a fix? Is someone trying to investigate?

[ixnij]

In my case, I installed stack via ghcup. I found that stack new project will be crash, but not after adding "-v". I'm using Alacritty and Terminal.app, zsh. Using bash can avoid the problem, but using yash or zsh can't.

wu@ThomasdeMacBook-Pro ~/Projects/Repositories % stack new myproj
[1]    40894 segmentation fault  stack new myproj
139 wu@ThomasdeMacBook-Pro ~/Projects/Repositories % yash
Welcome to yash!
....
wu@ThomasdeMacBook-Pro Repositories 2$ stack new proj
The process was killed by SIGSEGV: Segmentation fault: 11
wu@ThomasdeMacBook-Pro ~/Projects/Repositories % echo $TERM_PROGRAM
Apple_Terminal

[ixnij]

As a workaround I have created a small wrapper script that runs in Bash and passes its arguments along to stack along with the LLVM paths that GHC 8.10 currently needs, but this is of course far from ideal:

#!/bin/bash

export PATH="/opt/homebrew/opt/llvm@12/bin:$PATH"
export LDFLAGS="-L/opt/homebrew/opt/llvm@12/lib"
export CPPFLAGS="-I/opt/homebrew/opt/llvm@12/include"

/opt/homebrew/bin/stack "$@"

For ghcup users,

#!/usr/bin/env bash

export PATH="/opt/homebrew/opt/llvm@13/bin:$PATH"
export LDFLAGS="-L/opt/homebrew/opt/llvm@13/lib"
export CPPFLAGS="-I/opt/homebrew/opt/llvm@13/include"

$(ghcup whereis stack) "$@"

[niclas-ahden]

I tried three terminals and zsh/bash using:

• stack 2.7.5 aarch64 (tried both ghcup and brew)
• macOS Monterey 12.2.1 (aarch64 / Apple Silicon)

kitty 0.24.4

zsh$ stack exec -- yesod devel
[1]    92940 segmentation fault  stack exec -- yesod devel

bash-3.2$ stack exec -- yesod devel
Segmentation fault: 11

However, stack exec -v -- yesod devel works as expected.

stack --version works as expected with our without -v.

iTerm 2 Build 3.4.15 and macOS default Terminal 2.12 (443)

Everything works as expected using both zsh and bash.

[niclas-ahden]

I noticed that creating a new package with an invalid name works as intended (an error is printed):

zsh$ stack new invalid.name
Expected valid package name, but got: invalid.name
Package names consist of one or more alphanumeric words separated by hyphens.
To avoid ambiguity with version numbers, each of these words must contain at least one letter.


Usage: stack new PACKAGE_NAME [--bare] [TEMPLATE_NAME] [-p|--param KEY:VALUE] 
                 [DIR] [--omit-packages] [--force] [--ignore-subdirs] 
                 [--setup-info-yaml URL] [--snapshot-location-base URL] [--help]
  Create a new project from a template. Run `stack templates' to see available
  templates. Note: you can also specify a local file or a remote URL as a
  template.

But creating one with a valid name segfaults:

zsh$ stack new valid-name      
[1]    34017 segmentation fault  stack new valid-name

It ain't much, but hopefully it'll give an investigator a better idea of what's going on 🤞

I'm happy to test and/or provide more information if that'd be helpful.

PS. Tested in the same combinations as per my last comment, but now with macOS Monterey 12.3.1 and kitty 0.25.0.

PPS. I tested my setup (same version of kitty, dotfiles etc.) on two x86 machines and they worked as intended (Fedora 35 and an Intel Mac).

[gregatgoogle]

I ran into this issue as well, and adding the verbose flag helped. To add to what has been said:

1. this issue appears in stack instances installed through ghcup or brew, however, I did not see it when I installed stack using curl -sSL https://get.haskellstack.org/ | sh from https://docs.haskellstack.org/en/stable/install_and_upgrade/#installupgrade.
2. The --verbose doesn't help when I run a build command with --fast --file-watch, e.g., stack build -v --fast -file-watch.

[hasufell]

I ran into this issue as well, and adding the verbose flag helped. To add to what has been said:

1. this issue appears in stack instances installed through ghcup or brew, however, I did not see it when I installed stack using curl -sSL https://get.haskellstack.org/ | sh from https://docs.haskellstack.org/en/stable/install_and_upgrade/#installupgrade.

Guess why... because stack doesn't install aarch64 binaries on your mac M1. Brew and ghcup do.

M1 support in GHC is very new, so of course there may be some bugs. If anyone can pin this down, open a bug report for GHC.

[aleith]

subscribing for notifications on future fix/workarounds. On M1 Mac mini macOS 11.6.1. I can run GHCi on zsh but not GHCUP which I installed using bash. I only switched to zsh today after months of prompts on Terminal.app to do so. Cabal doesn't work either. I guess this was some kinda $PATH issue, but seems to be a bigger issue.

[yutotakano]

I have an M1 Mac as well and encountered this. I'm running the AArch64 based Stack in an AArch64 shell.

Below are some commands I ran to verify the architectures, and shows that adding the -v flag somehow changes the behaviour of the build command. I've tried also to build with the system GHC (which is also AArch64), but the segfault was still there.

After a single successful compilation with -v, all subsequent builds without that flag worked fine. This is for both the stack ghc and the system ghc.

zsh$ # Current shell arch
zsh$ arch
arm64

zsh$ # Architecture of the stack executable
zsh$ file $(where stack)
/Users/kilo/.ghcup/bin/stack: Mach-O 64-bit executable arm64

zsh$ #  For using --system-ghc, we get the architecture of the ghc in PATH
zsh$ file $(cat $(where ghc) | head -n 2 | tail -n 1 | awk -F'"' '{print $2}')/ghc
/Users/kilo/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/ghc: Mach-O 64-bit executable arm64

zsh$ # Try stack build
zsh$ stack build
zsh: segmentation fault  stack build

zsh$ # Try stack build with system-ghc
zsh$ stack build --system-ghc
zsh: segmentation fault  stack build

zsh$ stack build -v
Version 2.7.5, Git revision 717ec96c15520748f3fcee00f72504ddccaa30b5 (dirty) (163 commits) aarch64
Compiled with:
- Cabal-3.2.1.0
- Glob-0.10.1
- ....
# truncated but it all builds fine

zsh$ stack run --system-ghc -v
Version 2.7.5, Git revision 717ec96c15520748f3fcee00f72504ddccaa30b5 (dirty) (163 commits) aarch64
Compiled with:
- Cabal-3.2.1.0
- Glob-0.10.1
- ...
# Also truncated but it all builds fine

[bklebe]

Adding a slightly odd addendum here: on my machine it doesn't need to be bash, it just needs to be in a subshell. And adding -v/--verbose doesn't help. So for example:

$ stack ghci
zsh: segmentation fault  stack ghci
$ $(stack ghci)
…
ghci>

This suggests to me it's something about how stack attaches output to the terminal or something, which would explain why it's different between iTerm and Apple Terminal. But this is where my terminal knowledge ends. Any thoughts? Super weird bug here.

edit: this zsh behavior where it only works if you run it in a subshell also replicates in tcsh and ksh on my Mac.

[banzr]

Adding a slightly odd addendum here: on my machine it doesn't need to be bash, it just needs to be in a subshell. And adding -v/--verbose doesn't help. So for example:

$ stack ghci
zsh: segmentation fault  stack ghci
$ $(stack ghci)
…
ghci>

This suggests to me it's something about how stack attaches output to the terminal or something, which would explain why it's different between iTerm and Apple Terminal. But this is where my terminal knowledge ends. Any thoughts? Super weird bug here.

edit: this zsh behavior where it only works if you run it in a subshell also replicates in tcsh and ksh on my Mac.

I confirmed your finding on my mac also. If I run stack from a terminal, it works using bash or zsh. However, if I try running stack from ssh or through an emacs shell, it will segmentation fault 11 unless I call stack inside a subshell.