GHCI Segfault When Creating a Database Connection with postgresql-simple - haskell

Question

I am getting a GHCI segfault when trying to create a database connection in GHCI with postgresql-simple.
I am using GHC 8.0.1, OSX 10.11.16. I do not have a system GHC, only the one installed by stack.
If I do the following in my project, it segfaults:
$ stack ghci
Loaded GHCi configuration from /private/var/folders/wb/vvtxjd7n2qz02f571yjyr9j40000gs/T/ghci62972/ghci-script
gchi> :set -XOverloadedStrings
gchi> import Database.PostgreSQL.Simple
gchi> let connstr = "host=localhost port=5432 user=myusername password=mypass dbname=local"
gchi> conn <- connectPostgreSQL connstr
zsh: segmentation fault stack ghci
I thought it might be worth looking at that file it mentions, so here are the contents:
> cat /private/var/folders/wb/vvtxjd7n2qz02f571yjyr9j40000gs/T/ghci62972/ghci-script
:load "/Users/erewok/projects/haskell/simpleservantblog/app/Main.hs" "Api" "Api.Post" "Api.User" "Config" "Html.Home" "Models.Author" "Models.Post"
:module + Api Api.Post Api.User Config Html.Home Models.Author Models.Post
It's a list of all the modules loaded from the project (which compiles and runs fine).
Here's the complete output of everything from starting ghci up to the seg fault:
$ stack ghci
The following GHC options are incompatible with GHCi and have not been passed to it: -threaded
Using main module: 1. Package `simpleservantblog' component exe:simpleservantblog-exe with main-is file: /Users/erewok/projects/haskell/simpleservantblog/app/Main.hs
Configuring GHCi with the following packages: simpleservantblog
GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /Users/erewok/.ghci
[1 of 8] Compiling Models.Author ( /Users/erewok/projects/haskell/simpleservantblog/src/Models/Author.hs, interpreted )
[2 of 8] Compiling Models.Post ( /Users/erewok/projects/haskell/simpleservantblog/src/Models/Post.hs, interpreted )
[3 of 8] Compiling Html.Home ( /Users/erewok/projects/haskell/simpleservantblog/src/Html/Home.hs, interpreted )
[4 of 8] Compiling Api.User ( /Users/erewok/projects/haskell/simpleservantblog/src/Api/User.hs, interpreted )
[5 of 8] Compiling Api.Post ( /Users/erewok/projects/haskell/simpleservantblog/src/Api/Post.hs, interpreted )
[6 of 8] Compiling Config ( /Users/erewok/projects/haskell/simpleservantblog/src/Config.hs, interpreted )
[7 of 8] Compiling Api ( /Users/erewok/projects/haskell/simpleservantblog/src/Api.hs, interpreted )
[8 of 8] Compiling Main ( /Users/erewok/projects/haskell/simpleservantblog/app/Main.hs, interpreted )
Ok, modules loaded: Api, Config, Api.Post, Api.User, Html.Home, Models.Post, Models.Author, Main.
Loaded GHCi configuration from /private/var/folders/wb/vvtxjd7n2qz02f571yjyr9j40000gs/T/ghci64266/ghci-script
gchi> :set -XOverloadedStrings
gchi> import Database.PostgreSQL.Simple
gchi> let connstr = "host=localhost port=5432 user=myusername password=mypass dbname=local"
gchi> conn <- connectPostgreSQL connstr
zsh: segmentation fault stack ghci
More Information
Postgresql Version: 9.5, installed using the EnterpriseDB installer
The request to post my stack.yaml (which is below) reminded me of an issue I had when trying to install postgresql-libpq. This is probably related.
Stack.yaml
# This file was automatically generated by stack init
# For more information, see: http://docs.haskellstack.org/en/stable/yaml_configuration/
# Specifies the GHC version and set of packages available (e.g., lts-3.5, nightly-2015-09-21, ghc-7.10.2)
resolver: nightly-2016-08-25
# Local packages, usually specified by relative directory name
packages:
- '.'
- location:
git: https://www.github.com/mattjbray/elm-export
commit: 8868c1f09597f44c2e18e014cd9fbcf8320c3fea
extra-dep: True
- location:
git: https://www.github.com/mattjbray/servant-elm
commit: e13c8def8127ea339e9801d804638854947193e8
extra-dep: True
# Packages to be pulled from upstream that are not in the resolver (e.g., acme-missiles-0.3)
extra-deps:
- wai-make-assets-0.1.1
# Override default flag values for local packages and extra-deps
flags: {}
# Extra package databases containing global packages
extra-package-dbs: []
# Control whether we use the GHC we find on the path
# system-ghc: true
# Extra directories used by stack for building
# extra-include-dirs: [/path/to/dir]
extra-lib-dirs: [/usr/local/opt/libiconv/lib, /usr/local/lib, /usr/lib]
Also segfaults on GHC 7.10.3 with resolver lts-6.17
gchi> conn <- connectPostgreSQL connstr
zsh: segmentation fault stack ghci --resolver lts-6.17
An Idea I had
I think the version of postgresql-libpq I am using was built with libiconv.2.dylib compiled for Postgresql 9.4, but the database I am trying to connect to is actually Postgresql 9.5. This may be the reason for my issue.
A Thing I Did Inspired By that Idea
Here are some steps I took to try to debug further and/or fix this. I first linked the Postgresql 9.5 *dylib files into my /usr/local/lib directory in order to replace the old ones linked against the Postgresql 9.4 version.
$ cd /usr/local/lib
$ sudo ln -s -f /Library/PostgreSQL/9.5/lib/*dylib .
After that, I tried to force stack to rebuild postgresql-libpq and postgresql-simple in this way:
$ stack exec -- ghc-pkg unregister --force postgresql-simple
$ stack exec -- ghc-pkg unregister --force postgresql-libpq
$ rm -rf ~/.stack/precompiled/x86_64-osx/ghc-8.0.1/1.24.0.0/postgresql-libpq-0.9.1.1/
$ rm -rf ~/.stack/precompiled/x86_64-osx/ghc-8.0.1/1.24.0.0/postgresql-simple-0.5.2.*
$ stack build
At which point, it promised me it would build and configure the removed packages. Still segfaulted when I ran the above, however.

Answer 1

While attempting to generate a stack trace for my issue, I discovered that I can start ghci in the following way:
$ stack ghci --ghci-options -fexternal-interpreter
And then, for whatever, reason, the segfault does not appear and everything works as expected. I have no idea if anyone else will find this useful.
The thing that seemed weird to me was that I didn't have an issue when the code was compiled and run. I only had an issue in GHCI.
Anyway, until I find out more or someone has a better suggestion, I'll go with this so I can continue testing what I want in the REPL.