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

[Gilles Gouaillardet]

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 > 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 ' 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, 

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

[Jeff Squyres (jsquyres)]

Thanks for the report.  I don't know much about OSHMEM, but I'm guessing the 
files were laid out that way for a reason (e.g., maybe the OSHMEM spec calls 
for both of those files to exist?).

I've filed an issue here to track it:

https://github.com/open-mpi/ompi/issues/1868

Additionally, have you reported this issue upstream to cmake?  It seems like 
this is actually a bug in cmake and should be fixed.



> On Jul 13, 2016, at 7:30 AM, 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 > > 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 ' 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
>>

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

[Paul Kapinos]

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 > 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 ' 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




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

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

[Gilles Gouaillardet]

Paul,

The two header files in include/mpp simply include the file with the same
name in the upper directory.
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 ?

Cheers,

Gilles

On Wednesday, July 13, 2016, Paul Kapinos 
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 ' 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
>