https://bugs.exim.org/show_bug.cgi?id=2334
--- Comment #39 from Rich Siegel <siegel@???> ---
(In reply to Tim Stack from comment #37)
> Sorry to reopen, but there seems to be a bad interaction with MAP_JIT and
> fork() on macos. With the 8.43 release, if you jit compile a regex, then
> fork(), the child process will crash when trying to do a match or compiling
> a new regex. I compiled a version where MAP_JIT was not set and things
> worked fine.
I fear that you will have to find another way around this problem. I can
inquire, but I strongly suspect that macOS security engineering would consider
fork()ing a process in which MAP_JIT has been used to be a security risk.
(Aside: it would not go amiss for you to file a Radar with a test case,
particularly if you post the Radar number here.)
I don't know your project or requirements, but as a general advisory fork(2) is
very much not recommended on macOS, in favor of using posix_spawn(2) or NSTask
(if you are targeting macOS/iOS) or an XPC service (ditto). (This isn't a
"you're doing it wrong", this is a "I'm trying to think of ways you can get
around this issue.")
Alternatively, if it *is* your code, then doing the pcre[2]_compile() in the
child process *after* the fork might work as-is, if that's a feasible change
for you to make.
If it's not your code, I get how making significant changes could be
problematic and I am entirely sympathetic.
Finally: you can build PCRE without JIT support. This would be less than ideal,
but would solve your problem too.
In a larger sense, if use cases like these keep arising, it may be that the
only feasible solution in PCRE[2] is to provide an option flag to
pcre[2]_compile() to let the client unilaterally suppress PCRE's use of
MAP_JIT, because I don't think that it'll ever be possible to always make the
right decision at run time. (The default behavior should be what it is today:
let PCRE make the decision at runtime based on the OS version and environment.)
--
You are receiving this mail because:
You are on the CC list for the bug.
