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
<[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
