> On 1 Oct 2025, at 17:36, Andre Vehreschild <[email protected]> wrote:
>
> Hi Iain,
>
>> I wil try what has been suggested - but I guess that also applying the patch
>> series to current trunk ought to work?
>
> Well, there is an additional patch needed before the patch series (attached
> here).
thanks
>>
>>> When you then go to
>>>
>>> libgfortran/caf/shmem/shared_memory.c
>>>
>>> and search for "mmap" you'll see what I do. Yes, I know and tried
>>> MMAP_FIXED. It works for some cases and in other corrupts the address space
>>> on MacOS. (Works fine on Linux all the time). The base address is "send"
>>> from the supervisor process to its workers (called images in Fortran) using
>>> an environment variable. At the moment I am using the "proposal" method.
>>> I.e., I give MacOS the base address where I want that shared memory segment
>>> and just specify MMAP_SHARED.
>>
>> You might need to “propose” an address that is in a range that is not subject
>> to other uses (i.e. especially that other uses could have ALSR applied which
>> would mean that you’d see a random unavailablity). The sanitizers and the
>> PCH code both need to take this into account.
>
> Well, but it is shared(!) between processes. I would be fine with having the
> shared memory segment on different addresses in different processes, but then
> mutexes and condition variables do not function properly on macos anymore.
Well .. to some extent processes are independent. You start up the code and the
kernel will load your code (and the OS-provided libs) at random addresses +
likewise
for the heap and stack.
The ranges that these things can occupy is finite and thus it you want to
request
some explicit address, it’s necessary to pick one that does not overlap with one
of the used ranges.
>>> On Linux, I am done. I get the shared memory always on the desired address.
>>>
>>
>> Well - I’d assume that on Linux editions with PIE executables and ASLR
>> enabled
>> you’d have to make similar considerations? (I am not so familiar with these
>> facilities on Linux).
>
> I have never ran into this. And I am on a recent kernel 6.16.something and the
> randomize_va_space flag shows 2, which to what a quick search means, that ASLR
> is enabled. Furthermore I am requesting the OS to hand me a shared memory
> segment. I use shm_open and all the good stuff to let the OS know, that I am
> really intending to share the memory between processes. Therefore I do see no
> reason to have ASLR or what it is called on MacOS to interfere. But odd things
> happen.
I see - but you are not using shm_open on macOS ?
(apologies, I did not look at the code yet)
>>> On MacOS the address is sometimes accepted on the first try, and sometimes
>>> needs several thousand tries to be accepted. But finally MacOS accepts it.
>>> This is so indeterministic to me.
>>
>> I expect that is totally intentional :) .. if you have an address in a range
>> that conflicts with ALSR.
>
> I imagine, I do get this only when the OS has put a segment of the program's
> text/code into the space I now like the shared segment to be, but I haven't
> found a way to tell the OS directly after the fork() to reserve the space.
> Then
> after the execve of the same executable, the address space would be free, or
> adviced or whatever. Do you have any idea how to accomplish that?
>
>>>
>>> I am really curious what I am doing wrong for MacOS being so exceptional.
>>
>> it’s plausibly not only the OS - but also the default conditions that apply
>> on the OS - for macOS: PIE and ASLR are defaults (and on Arm64 macOS mandated
>> by security policy). That might not be the situation on the Linux
>> distribution you are using (IDK, just speculating).
>
> Mhhh, may be the different OSes just do it differently.
yeah .. quite possibly.
> I am quite positive
> that Linux uses ASLR and my fortran programs all are position independent. I
> added -fPIE to a compile run and the resulting executable did not change to a
> compile without it.
great!
Iain
>
> Regards,
> Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
> <coarray_fixes_4.patch>
