I started getting a Bad address error when executing processes after updating from lts-18.5 to lts-18.10, which brings process from v1.6.9.0 to v1.6.13.2. It seems to be related to setting cwd and env in the CreateProcess.
Everything works fine if you don't change env. You can touch env, if you don't change cwd too. You can change env and change cwd, but depending on what you are changing cwd to and how that affects the command. For example, cwd = /bin and a command of ./true works fine even when changing env. Unfortunately, I have not been able to narrow down the pattern in that last variability. Note that setting cwd to . (or the full path to .) does not count as "change" for this issue, but setting env to the result of getEnvironment does. Straight-forward, right?
So, there are a lot of different combinations that trigger it, but here is one minimal repro:
% tree
.
├── Main.hs
└── sub
└── exe
1 directory, 2 files% cat sub/exe
#!/bin/sh
true
-- Main.hs
{-# LANGUAGE TypeApplications #-}
module Main where
import Prelude
import Control.Exception (SomeException, try)
import System.Environment (getEnvironment)
import System.Process
main :: IO ()
main = do
currentEnv <- getEnvironment
let cp = (proc "./exe" []) { cwd = Just "./sub", env = Just currentEnv }
x <- try @SomeException $ withCreateProcess cp $ \_ _ _ -> waitForProcess
print xWorks in 18.5, not in 18.10:
% stack --resolver lts-18.5 runhaskell Main.hs
Right ExitSuccess
% stack --resolver lts-18.10 runhaskell Main.hs
Left ./exe: createProcess: exec: failed (Bad address)
Note that it is indeed isolated to process: I can use 18.10 with an extra-dep of process-1.6.9.0 and the bug goes away. I'm just not showing it that way because it requires more setup to repro.
I experienced this in typed-process (using setWorkingDir and setEnv), but eventually found the bug to be here.
I started getting a
Bad addresserror when executing processes after updating fromlts-18.5tolts-18.10, which bringsprocessfromv1.6.9.0tov1.6.13.2. It seems to be related to settingcwdandenvin theCreateProcess.Everything works fine if you don't change
env. You can touchenv, if you don't changecwdtoo. You can changeenvand changecwd, but depending on what you are changingcwdto and how that affects the command. For example,cwd = /binand a command of./trueworks fine even when changingenv. Unfortunately, I have not been able to narrow down the pattern in that last variability. Note that settingcwdto.(or the full path to.) does not count as "change" for this issue, but settingenvto the result ofgetEnvironmentdoes. Straight-forward, right?So, there are a lot of different combinations that trigger it, but here is one minimal repro:
Works in 18.5, not in 18.10:
Note that it is indeed isolated to
process: I can use18.10with anextra-depofprocess-1.6.9.0and the bug goes away. I'm just not showing it that way because it requires more setup to repro.I experienced this in
typed-process(usingsetWorkingDirandsetEnv), but eventually found the bug to be here.