[pcre-dev] [Bug 2334] "make test" reports test failures when…

Pàgina inicial
Delete this message
Autor: admin
Data:  
A: pcre-dev
Assumptes vells: [pcre-dev] [Bug 2334] New: "make test" reports test failures when running on macOS (x86_64)
Assumpte: [pcre-dev] [Bug 2334] "make test" reports test failures when running on macOS (x86_64)
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.