https://bugs.exim.org/show_bug.cgi?id=2334
--- Comment #6 from Rich Siegel <siegel@???> ---
So, I was the macOS user who asked Zoltan to add MAP_JIT to the mmap() flags.
:-D
This flag is necessary for compatibility with the macOS 10.14 "hardened
runtime", which is a code-signing option that can be set by the developer at
build time.
It sounds as though using MAP_JIT causes mmap() to fail when the hardened
runtime is _not_ in use, which sounds like a bug in the OS to me, but I'm sure
that's one of those things that we can't expect to get fixed by Apple any time
soon.
Thus, the solution probably involves writing a function which determines
whether the current executable is signed with the "hardened runtime" flag; and
if so, use MAP_JIT, and if not, don't.
As it happens, I know how to do this, so I will be happy to code it up and test
it here, and attach it once I have it sorted out. Naturally it'll be
platform-specific code, and I leave it to you to determine how to best
integrate it.
As to the heap limit: in fact when configuring my build, I *increased* the heap
limit, to 64MB.
The output of pcre2test -C is as follows:
RocketSled:pcre2 siegel$ ./pcre2test -C
PCRE2 version 10.33-RC1 2018-09-14
Compiled with
8-bit support
16-bit support
UTF and UCP support (Unicode version 11.0.0)
Just-in-time compiler support: x86 64bit (little endian + unaligned)
Newline sequence is LF
\R matches all Unicode newlines
\C is supported
Internal link size = 4
Parentheses nest limit = 250
Default heap limit = 67108864
Default match limit = 10000000
Default depth limit = 10000000
However, if I delete my customized entry and let ccmake generate a new one
which defaults to 20000000, pcre2_test succeeds:
RocketSled:pcre2 siegel$ ./pcre2test -C
PCRE2 version 10.33-RC1 2018-09-14
Compiled with
8-bit support
16-bit support
UTF and UCP support (Unicode version 11.0.0)
Just-in-time compiler support: x86 64bit (little endian + unaligned)
Newline sequence is LF
\R matches all Unicode newlines
\C is supported
Internal link size = 4
Parentheses nest limit = 250
Default heap limit = 20000000
Default match limit = 10000000
Default depth limit = 10000000
Some more experiments:
default heap limit = 50331648 (48MB): Fail
default heap limit = 33462272 (32MB): Pass
...so there is something going on there. Perhaps overflow with large heap
limits?
--
You are receiving this mail because:
You are on the CC list for the bug.
