Hello Oskar, I'm copying this to the mailing list since I think it may be of wider interest.
Thank you for investigating the problem. I've looked into this and found that there is problem with mprotect sometimes failing and this seems to be a bug in Mac OS. I've pushed a fix but I wasn't able to test your specific example so maybe you can try it and let me know if the fix has worked.
Mac OS has introduced a restriction that prevents a thread from simultaneously having write and execute access to a page. This seems to affect ARM code but it doesn't look as though it's enabled with X86 code under Rosetta. Inevitably, being Apple, they have taken a different approach from SELinux and OpenBSD so I've had to add special code when allocating areas of memory for code in Mac OS on ARM. It looks as though mprotect on Mac OS can return an error if it is called a second time with the same arguments. That looks like a kernel bug to me. The problem is still there in the latest kernel, 20.3.0. I've worked around it by ignoring any error from mprotect since in this particular case the previous protection state is fine.
David
On 31/10/2021 13:45, Oskar Abrahamsson wrote:
Hello David,
Here is a bug that manifests itself with a Poly/ML compiler built on/for macOS-arm64, but not when the same compiler is built using Rosetta on the same machine. Here is the output from 'poly -v' for these compilers:
? Poly/ML 5.9 Release ? ?RTS version: Arm64-5.9 (Git version v5.8.2-324-g960de0cd) ? Poly/ML 5.9 Release ? ?RTS version: X86_64-5.9 (Git version v5.8.2-324-g960de0cd)
Both compilers are built in the same way (./configure, then make, then make compiler) but with all calls prefixed with ?arch -x86_64? for the Rosetta compiler.
Here is the bug: polyc dies when attempting to build src/poly-mlyacc.ML from this code: https://github.com/HOL-Theorem-Prover/HOL/tree/develop/tools/mlyacc https://github.com/HOL-Theorem-Prover/HOL/tree/develop/tools/mlyacc. To reproduce, go to src/ and run 'polyc poly-mlyacc.ML'. ?Here is the failure:
? ? Exception- Fail "Insufficient Memory" raised
I managed to find a failing call to mprotect which leads to the message above being shown during export, by looking at output generated from polyc when called with the --debug saving and --debug memmgr flags. Here are the last few lines of that output:
? ? SAVE: Allocated graveyard for permanent space, 0x138008000 size: 4340064. ? ? SAVE: Allocated graveyard for permanent space, 0x138430000 size: 7542328. ? ? SAVE: Allocated graveyard for permanent space, 0x138b68000 size: 510648. ? ? SAVE: Allocated graveyard for permanent space, 0x138be8000 size: 344120. ? ? SAVE: Copyscan default sizes: Immutable: 1048576, Mutable: 1048576, Code: 1048576, No-overwrite 4096. ? ? MMGR: New export immutable space 0x600001004000, size=1024k words, bottom=0x106aec000, top=0x1072ec000 ? ? MMGR: New export immutable space: insufficient space ? ? SAVE: Unable to allocate export space, size: 1048576. ? ? Exception- Fail "Insufficient Memory" raised ? ? MMGR: Deleted stack space 0x600001800dc0 at 0x1092ec000 size 262144 ? ? MMGR: Deleted stack space 0x600001804000 at 0x10559c000 size 2048
The ?MMGR: New export immutable space: insufficient space? message seems to appear because space->bottom == 0 at line 441 in libpolyml/memmgr.cpp,?and the reason why space->bottom == 0 is because the call to mprotect at line 330 in libpolyml/osmemunix.cpp fails with ENOACCES.
If there is any other information that I can provide that would be more helpful, please let me know.
? Oskar
On 30 Oct 2021, at 09:50, David Matthews <David.Matthews at prolingua.co.uk <mailto:David.Matthews at prolingua.co.uk>> wrote:
I'm intending to release the current master on github as version 5.9 in the near future. ?Could I ask everyone to give it a try and let me know if there are any serious bugs that need to be fixed. ?The main differences are the ARM64 code-generator, the new bootstrap process and position-independent code. This was described in greater detail back in May http://lists.inf.ed.ac.uk/pipermail/polyml/2021-May/002451.html http://lists.inf.ed.ac.uk/pipermail/polyml/2021-May/002451.html . There have also been other smaller changes and fixes.
David _______________________________________________ polyml mailing list polyml at inf.ed.ac.uk <mailto:polyml at inf.ed.ac.uk> http://lists.inf.ed.ac.uk/mailman/listinfo/polyml