Re: Update on shared memory coarrays

[dhumieres.dominique@free.fr]

Le 2020-12-22 16:10, Thomas Koenig a écrit :
> Hi Dominique,
> 
>> Indeed! I can try to do some debugging under supervision.
>> Could you please tell me where to start?
> 
> Thanks for your offer.
> 
> The first thing to do would be to see where it hangs.  Generating
> a syscall trace (by whatever tool is used on MacOS, dtrace? ktrace?)
> would be a first step.
> 
> A next step would be to compile a program with debug info and
> run it under a debugger, then see where it hangs.
> 
> I'm not sure - do you use gdb on your system?  If you do,
> the following lines in your .gdbinit
> 
> define better_mp_debug
>   set detach-on-fork off
>   set schedule-multiple on
>   set follow-fork-mode parent
>   set non-stop on
>   set target-async on
>   set print symbol-loading off
> end
> 
> will give you a macro "better_mp_debug" which will ease debugging
> of forked processes enormously.
> 
> My lack of experience with MacOS extends to which tools to use
> for debugging, unfortunately.
> 
> Best regards
> 
> 	Thomas

Running the hello test under lldb with breakpoints at 
ensure_initialization
and get_shmem_fd gives a first stop at __gfortran_cas_master,
a second one at __gfortrani_ensure_initialization, and a third one at
__gfortrani_ensure_initialization. Then if I adavance step by step
the program seems to loop in

   do
     {
       snprintf (buffer, sizeof (buffer), MEMOBJ_NAME "_%u_%d",
                 (unsigned int)getpid (), id++);
       fd = shm_open (buffer, O_RDWR | O_CREAT | O_EXCL, S_IRUSR | 
S_IWUSR);
     }
   while (fd == -1);

fd is always -1 and

(lldb) p errno
(void *) $1 = 0x000000000000003f

I don't see anything wrong with shm_open.
In the config.log I see both

ac_cv_func_shm_open=yes
ac_cv_func_shm_unlink=yes

and

ac_cv_lib_pthread_pthread_create=yes
ac_cv_lib_rt_shm_open=no

What should I do next?

TIA

Domonique