Re: [OMPI devel] SHMEM, "mpp/shmem.fh", CMake and infinite loops

Wed, 13 Jul 2016 20:07:46 -0400 (EDT) 

Paul,


thanks for testing the workaround

/* i was on a trip and could not do it myself */
At first glance, i agree with Jeff and the root cause seems to be a CMake bug.
/* i cannot find any rationale for automatically including some directories that were not requested by the user */
note that even if you could limit the recursion depth with an appropriate CMake option, that would some the infinite loop,
but dependencies would be incorrect (e.g. shmem.fh from the upper directory would be missing)
That being said, i am more pragmatic that dogmatic, so i am fine updating OpenMPI so it avoids a CMake bug, 

let's follow up at https://github.com/open-mpi/ompi/issues/1868


Cheers,


Gilles


On 7/13/2016 8:30 PM, Paul Kapinos wrote:

Hi Gilles,

On 07/13/16 01:10, Gilles Gouaillardet wrote:

Paul,
The two header files in include/mpp simply include the file with the same name 
in the upper directory.


Yessir!
(and CMake do not care about the upper directory and build infinite loop)
A simple workaround is to replace these two files in include/mpp with symbolic 
links to files with the same name in the upper directory.

Would you mind giving this a try ?
It work very well, at least for the one test case provided. So yes, patching any installation of Open MPI could be a workaround. However we would really love to avoid this need to patch any Open MPI installation
Maybe OpenMPI's developer could think about how-to minimize the probability of such loops? Symlink is one alternative, another one would be renaming one of the headers.. 
we fully trust to Open MPI's developers expertise in this :-)

Have a nice day,

Paul Kapinos
pk224850@linuxc2:/opt/MPI/openmpi-1.8.1/linux/intel/include[519]$ ls -la mpp/shmem.fh lrwxrwxrwx 1 pk224850 pk224850 11 Jul 13 13:20 mpp/shmem.fh -> ../shmem.fh 



Cheers,

Gilles

On Wednesday, July 13, 2016, Paul Kapinos <kapi...@itc.rwth-aachen.de
<mailto:kapi...@itc.rwth-aachen.de>> wrote:

    Dear OpenMPI developer,
we have some troubles when using OpenMPI and CMake on codes using 'SHMEM'. 

    Cf. 'man shmem_swap',
     >       Fortran:
     >       INCLUDE "mpp/shmem.fh"

    Yes here is one such header file:
     > openmpi-1.X.Y/oshmem/include/mpp/shmem.fh
    ... since version 1.7. at least.


    The significnat content is this line:
     >      include 'shmem.fh'
whereby OpenMPI mean to include not the same file by itself (= infinite 
    loop!) but I believe these one file:
     > openmpi-1.X.Y/oshmem/include/shmem.fh
(The above paths are in the source code distributions; in the installation 
    the files are located here:  include/shmem.fh include/mpp/shmem.fh)
This works. Unless you start using CMake. Because CMake is 'intelligent' and try to add the search paths recursively, (I believe,) gloriously enabling the infinite loop by including the 'shmem.fh' file from the 'shmem.fh' file. 

    Steps to repriduce:
    $ mkdir build; cd build; cmake ..
    $ make
The second one command need some minute(s), sticking by the 'Scanning 
    dependencies of target mpihelloworld' step.
If connecting by 'strace -p <PID>' to the 'cmake' process you will see lines like below, again and again. So I think CMake just include the 'shmem.fh' file from itself unless the stack is full / a limit is reached / the moon shines, and thus hangs for a while (seconds/minutes) in the 'Scanning 
    dependencies...' state.
*Well, maybe having a file including the same file is not that good?* 
    If the file 'include/mpp/shmem.fh' would include not 'shmem.fh' but
'somethingelse.fh' located in 'include/...' these infinite loop would be 
    impossible at all...
And by the way: is here a way to limit the maximum include depths in CMake for header files? This would workaround this one 'infinite include loop' 
    issue...

    Have a nice day,

    Paul Kapinos

    ..............
access("/opt/MPI/openmpi-1.10.2/linux/intel_16.0.2.181/include/mpp/shmem.fh", R_OK) 
    = 0
stat("/opt/MPI/openmpi-1.10.2/linux/intel_16.0.2.181/include/mpp/shmem.fh",
    {st_mode=S_IFREG|0644, st_size=205, ...}) = 0
open("/opt/MPI/openmpi-1.10.2/linux/intel_16.0.2.181/include/mpp/shmem.fh",
    O_RDONLY) = 5271
    fstat(5271, {st_mode=S_IFREG|0644, st_size=205, ...}) = 0
mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
    0x7f08457d2000
    read(5271, "!\n!   Copyright (c) 2013      Me"..., 32768) = 205
    read(5271, "", 32768)                   = 0
access("/opt/MPI/openmpi-1.10.2/linux/intel_16.0.2.181/include/mpp/shmem.fh", R_OK) 
    = 0
stat("/opt/MPI/openmpi-1.10.2/linux/intel_16.0.2.181/include/mpp/shmem.fh",
    {st_mode=S_IFREG|0644, st_size=205, ...}) = 0
open("/opt/MPI/openmpi-1.10.2/linux/intel_16.0.2.181/include/mpp/shmem.fh",
    O_RDONLY) = 5272
    fstat(5272, {st_mode=S_IFREG|0644, st_size=205, ...}) = 0
mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
    0x7f08457ca000
    read(5272, "!\n!   Copyright (c) 2013      Me"..., 32768) = 205
    read(5272, "", 32768)                   = 0
    ..............

    --
    Dipl.-Inform. Paul Kapinos   -   High Performance Computing,
    RWTH Aachen University, IT Center
    Seffenter Weg 23,  D 52074  Aachen (Germany)
    Tel: +49 241/80-24915



_______________________________________________
devel mailing list
de...@open-mpi.org
Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/devel
Link to this post: http://www.open-mpi.org/community/lists/devel/2016/07/19195.php 






_______________________________________________
devel mailing list
de...@open-mpi.org
Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/devel
Link to this post: 
http://www.open-mpi.org/community/lists/devel/2016/07/19196.php

Reply via email to