Repository navigation
Bad address when using relative cwd and setting env #219
Description
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.
Activity
snoyberg commentedon Oct 13, 2021
@bgamari you think this could be related to #208?
@pbrisbin would you be able to narrow this down to a specific
processversion that introduces the breakage?pbrisbin commentedon Oct 13, 2021
Good call. Let me do a little manual bisect with
extra-depsof the versions between.pbrisbin commentedon Oct 13, 2021
I can confirm process-1.6.12.0 does not reproduce the issue, and process-1.6.13.1 does.
I cannot test process-1.6.13.0 because I get a different error,
snoyberg commentedon Oct 13, 2021
Thanks @pbrisbin. That makes it look pretty likely that #208 is at play here.
pbrisbin commentedon Oct 13, 2021
😬 😱
bgamari commentedon Jan 11, 2022
Apologies for missing this earlier, @snoyberg! I'll investigate.
bgamari commentedon Jan 11, 2022
Yes, I see the problem here.
find_executablefails to account for the change in working directory when searching for the target executable.posix: Ensure that find_executable accounts for working directory
posix: Ensure that find_executable accounts for working directory
posix: Ensure that find_executable accounts for working directory
Merge pull request #229 from bgamari/wip/T219