https://bugs.exim.org/show_bug.cgi?id=2334
--- Comment #39 from Rich Siegel <sie...@barebones.com> --- (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. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
