createProcess segfaults on Mac

[neilmayhew]

The following test case produces a segfault with ghc-9.4.5 on Mac. The version of process is 1.6.16.0.

import Control.Monad
import System.Process

main :: IO ()
main = void $ createProcess $ CreateProcess
    { child_group = Nothing
    , child_user = Nothing
    , close_fds = False
    , cmdspec = RawCommand "env" []
    , create_group = True
    , create_new_console = False
    , cwd = Nothing
    , delegate_ctlc = False
    , detach_console = False
    , env = Just [("PATH", "/bin:/usr/bin")]
    , new_session = False
    , std_err = Inherit
    , std_in = Inherit
    , std_out = Inherit
    , use_process_jobs = False
    }

I used the copy of ghc installed by stack:

$ ~/.stack/programs/x86_64-osx/ghc-9.4.5/bin/runghc TestCase.hs
Segmentation fault: 11
$ ~/.stack/programs/x86_64-osx/ghc-9.4.5/bin/ghc-pkg list process
~/.stack/programs/x86_64-osx/ghc-9.4.5/lib/ghc-9.4.5/lib/package.conf.d
    process-1.6.16.0

It's crashing in strlen:

$ lldb TestCase
(lldb) target create "TestCase"
Current executable set to '~/portal-suite/devtools/gabe/test/TestCase' (x86_64).
(lldb) r
Process 65154 launched: '~/portal-suite/devtools/gabe/test/TestCase' (x86_64)
Process 65154 stopped
* thread #1, name = 'ghc_ticker', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00007ff8189646b2 libsystem_platform.dylib`_platform_strlen + 18
libsystem_platform.dylib`:
->  0x7ff8189646b2 <+18>: pcmpeqb (%rdi), %xmm0
    0x7ff8189646b6 <+22>: pmovmskb %xmm0, %esi
    0x7ff8189646ba <+26>: andq   $0xf, %rcx
    0x7ff8189646be <+30>: orq    $-0x1, %rax
Target 0: (TestCase) stopped.
(lldb) p $rdi
(unsigned long) $0 = 0
(lldb) bt
* thread #1, name = 'ghc_ticker', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00007ff8189646b2 libsystem_platform.dylib`_platform_strlen + 18
    frame #1: 0x000000010000d0ae TestCase`find_executable + 142
    frame #2: 0x000000010000c873 TestCase`do_spawn_fork + 99
    frame #3: 0x000000010000c6bd TestCase`runInteractiveProcess + 429
    frame #4: 0x0000000100010ce1 TestCase`Lc5h0_info + 113

Although the backtrace says it's in find_executable, I think it's actually in find_in_search_path which has been inlined by the C compiler:

static char *find_in_search_path(char *working_dir, char *search_path, const char *filename) {
    int workdir_len = strlen(working_dir);

It doesn't crash when the Haskell cwd value is a Just.

[neilmayhew]

It doesn't crash on Linux, and I suspect this is because HAVE_EXECVPE is defined and find_executable isn't used.

[neilmayhew]

cc @philderbeast

[snoyberg]

CC @bgamari

[neilmayhew]

I'm working on a PR. Should have it ready in a couple of hours.

[andreasabel]

Seems like this regression was introduced in PR #229 released with 1.6.14.0.
The following table shows which latest minor versions of GHC suffer from the bug.

GHC	process	segfault
9.0.2	1.6.13.2	no
9.2.8	1.6.16.0	yes
9.4.7	1.6.17.0	yes
9.6.3	1.6.17.0	yes
9.8.0	1.6.18.0	no

Unfortunately, that includes 9.4.7 and 9.6.3 that were released after the bug had been fixed.
I hope we'll get some updates of 9.4 and 9.6 that bump to 1.6.18.0 to fix the problem.
ATTN: @bgamari

[wz1000]

process 1.6.18.0 was released on 2023-09-20, which is after the release of 9.4.7 and just a few days before the release of 9.6.3, which is cutting it very close for new/untested submodule bumps.

[andreasabel]

process 1.6.18.0 was released on 2023-09-20,

... by (a member of) the GHC team, one should add.

But the future interests me more than the past: Would be great to see updates of 9.4 and 9.6 with the new process library!