`runInputT` crashes when executed in more than one thread
- Dominant language
- Haskell
- Stars
- 247
- Forks
- 82
- PR merge metrics
- No merged PRs in 30d
Description
The following program crashes with low-level memory errors (seg.fault, double-free, ...) when executed with more than one OS thread.
```
module Main where
import Control.Concurrent (forkIO, threadDelay)
import System.Console.Haskeline (runInputT, defaultSettings)
main :: IO ()
main = do
forkIO inputT
forkIO inputT
threadDelay 1
where
inputT = runInputT defaultSettings $ pure ()
```
```
jost@freshcode-1:~/work/RV/code/scratch/haskeline-issue-ghc-927$ ghc-9.2.7 -package haskeline crashMe.hs -o crashMe -threaded -with-rtsopts "-N2"
jost@freshcode-1:~/work/RV/code/scratch/haskeline-issue-ghc-927$ while ./crashMe; do echo "worked, again"; done
free(): double free detected in tcache 2
Aborted (core dumped)
jost@freshcode-1:~/work/RV/code/scratch/haskeline-issue-ghc-927$ while ./crashMe; do echo "worked, again"; done
worked, again
worked, again
worked, again
worked, again
worked, again
worked, again
Segmentation fault (core dumped)
jost@freshcode-1:~/work/RV/code/scratch/haskeline-issue-ghc-927$
```
Is this expected (i.e., is `haskeline`'s `InputT` known to not be thread-safe?
The issue happens for us when running unit tests in parallel so we can work around it, but it is somewhat ugly how it fails.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the runInputT reproducer in the issue and run it with GHC's threaded runtime and -N2 to confirm the failure. Trace the concurrent InputT execution to identify the source of the memory errors, then make the behavior safe or clearly establish the thread-safety limitation and verify the result with a parallel test.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- haskell
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100