https://bugs.exim.org/show_bug.cgi?id=2334
--- Comment #6 from Rich Siegel <[email protected]> --- 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. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
