Thanks eskimo for your reply. It is the first clear answer I found after struggling against this problem since I got my new macbook M2 a few weeks ago. But your "recommended" advise "You can raise this issue with your tool’s vendor via their support channel" is not relevant at all. All the mac users are not using tools having a "vendor"! Mac computers are extensively used in the academic research, where people develop their own codes in various domains, and do not use any commercial codes with "vendors". That is my case. Changing the way memory is allocated in my codes will be a huge piece of work. I don't really understand what changed concerning the memory management on M procs and why it has been done but it is really a bad news. I had hopped that some compiler options or system configuration could fix the problem but your post is quite clear about that.
efji
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Post
Replies
Boosts
Views
Activity
Well, I have written the simplest program to describe the problem: 7 lines of fortran!
parameter (n=267500000)
real*8 x(n)
c common /bid/ x
c
do i=1,n
x(i)=i
enddo
print*,x(n)
end
n=267500000 is the limit I found by trial an error. It is 1.993 GB. This program works, while it fails with n=267600000 (1.9938 GB)
dyld[41138]: dyld cache '(null)' not loaded: syscall to map cache into shared region failed
dyld[41138]: Library not loaded: /usr/lib/libSystem.B.dylib
Referenced from: <2B29D6C7-6D46-3945-9ABD-055CC298981B> /Users/jouve/Test_mem/testmem
Reason: tried: '/usr/lib/libSystem.B.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/lib/libSystem.B.dylib' (no such file), '/usr/lib/libSystem.B.dylib' (no such file, no dyld cache), '/usr/local/lib/libSystem.B.dylib' (no such file)
Putting the big array in a common zone (which is commented here) is a classical way to avoid the limits on stack size, but does not change anything here.
The line "print" is only there to avoid smart compilers to "optimize" the whole program and reduce it to nothing if they find out that this piece of code does nothing at all :)
Of course it works on old Mac-intels and linux computers with any value of "n".