headers
Anton Shterenlikht | 10 Feb 11:08
Picon
Picon
Favicon

gfortran47, pgf90 work - ifort segfaults

On Linux 2.6.18-194.32.1.el5 #1 SMP x86_64 x86_64 x86_64
I've 3 compilers:

Portland: pgf90 11.10-0 64-bit target on x86-64 Linux -tp penryn 
GCC: 4.7.0 20120128
Intel: 12.0.2 20110112

The code below segfaults only when compiled with Intel compiler.
Before blaming an Intel compiler bug,
what could be wrong with this code:

bigblue4> cat z.f90 
program z

 integer,parameter :: ou=101

 integer :: space1(0:201,0:201,0:201)

 space1=12345

 open(unit=ou,file="test", form="unformatted", &
   access="stream", status="replace")

 write(unit=ou) space1(1:201,:,:)

 close(unit=ou)

 end
bigblue4> gfortran z.f90 
bigblue4> ./a.out
(Continue reading)

Permalink | Reply |
headers
Tobias Burnus | 10 Feb 11:40
Picon

Re: gfortran47, pgf90 work - ifort segfaults


On 02/10/2012 11:08 AM, Anton Shterenlikht wrote:
> Intel: 12.0.2 20110112
> The code below segfaults only when compiled with Intel compiler.

The code looks valid - and using ifort 11.1, 12.0.3 and 12.1.1, it does 
not crash for me; thus, it could be fixed in later 12.0.x versions or 
might have different reasons.

On issue which can lead to segfaults is a too small stack. And in 
particular the Intel compiler uses a lot of stack space by default. 
Stack memory is fast - faster than memory allocated on the heap. But the 
down side is: By default the available stack size is rather limited. 
Thus, one easily runs into stack issues. Having large arrays can require 
a lot of stack size - exceeding the available space leads to segfaults.  
If ifort places "space1" on the stack, you need 31.5 MB stack space. 
That's not very much but might be still too much. Could you check what 
"ulimit -s" (POSIX shell, bash) or "limit stack" (csh, tcsh) prints?

> I know it's something to do with stream output
> and array indexing. If I modify the write
> line to either of these:
>   write(unit=ou) space1
>   write(unit=ou) space1(:,:,:)
>   write(unit=ou) space1(0:201,:,:)
> there is no segfault with intel.
>
> However, these do segfault with intel:
>   write(unit=ou) space1(1:200,:,:)
>   write(unit=ou) space1(0:200,:,:)
(Continue reading)

Permalink | Reply |
headers
Anton Shterenlikht | 10 Feb 12:43
Picon
Picon
Favicon

Re: gfortran47, pgf90 work - ifort segfaults

On Fri, Feb 10, 2012 at 11:40:55AM +0100, Tobias Burnus wrote:
> 
> On 02/10/2012 11:08 AM, Anton Shterenlikht wrote:
> >Intel: 12.0.2 20110112
> >The code below segfaults only when compiled with Intel compiler.
> 
> The code looks valid - and using ifort 11.1, 12.0.3 and 12.1.1, it does 
> not crash for me; thus, it could be fixed in later 12.0.x versions or 
> might have different reasons.
> 
> On issue which can lead to segfaults is a too small stack. And in 
> particular the Intel compiler uses a lot of stack space by default. 
> Stack memory is fast - faster than memory allocated on the heap. But the 
> down side is: By default the available stack size is rather limited. 
> Thus, one easily runs into stack issues. Having large arrays can require 
> a lot of stack size - exceeding the available space leads to segfaults.  
> If ifort places "space1" on the stack, you need 31.5 MB stack space. 
> That's not very much but might be still too much. Could you check what 
> "ulimit -s" (POSIX shell, bash) or "limit stack" (csh, tcsh) prints?

Tobias, thanks, you are right:

% ifort z.f90 
% limit stack
stacksize    10240 kbytes
% ./a.out 
Segmentation fault
% limit stack 100000
% ./a.out 
%
(Continue reading)

Permalink | Reply |
headers
Arjen Markus | 10 Feb 12:51
Picon

Re: gfortran47, pgf90 work - ifort segfaults

Hello Anton,

2012/2/10 Anton Shterenlikht <mexas <at> bristol.ac.uk>:

> Tobias, thanks, you are right:
>
> % ifort z.f90
> % limit stack
> stacksize    10240 kbytes
> % ./a.out
> Segmentation fault
> % limit stack 100000
> % ./a.out
> %
>
> How is stack space related to the available RAM?
> I naively assumed that if I have e.g. 8GB RAM in a node,
> I can operate with, say, 7GB RAM arrays, and leave
> the remaining 1GB  for the OS needs. I guess this
> is far too simple a view?
>
> Maybe you can point me to a good resource to
> read more on this. I don't want to take too much
> of your time.
>

I know of no such a resource, but the stack space allowed to a program
is something that the OS is responsible for, not the hardware.
You found the way to increase the available stack space on Linux.
On Windows you have to do it by telling the linker to make the
(Continue reading)

Permalink | Reply |
headers
Anton Shterenlikht | 10 Feb 13:37
Picon
Picon
Favicon

Re: gfortran47, pgf90 work - ifort segfaults

On Fri, Feb 10, 2012 at 12:51:47PM +0100, Arjen Markus wrote:
> Hello Anton,
> 
> 2012/2/10 Anton Shterenlikht <mexas <at> bristol.ac.uk>:
> 
> > Tobias, thanks, you are right:
> >
> > % ifort z.f90
> > % limit stack
> > stacksize    10240 kbytes
> > % ./a.out
> > Segmentation fault
> > % limit stack 100000
> > % ./a.out
> > %
> >
> > How is stack space related to the available RAM?
> > I naively assumed that if I have e.g. 8GB RAM in a node,
> > I can operate with, say, 7GB RAM arrays, and leave
> > the remaining 1GB  for the OS needs. I guess this
> > is far too simple a view?
> >
> > Maybe you can point me to a good resource to
> > read more on this. I don't want to take too much
> > of your time.
> >
> 
> I know of no such a resource, but the stack space allowed to a program
> is something that the OS is responsible for, not the hardware.
> You found the way to increase the available stack space on Linux.
(Continue reading)

Permalink | Reply |
headers
Arjen Markus | 10 Feb 13:45
Picon

Re: gfortran47, pgf90 work - ifort segfaults

Hi Anton,

2012/2/10 Anton Shterenlikht <mexas <at> bristol.ac.uk>:

> What is "explicit allocation"?
>

Sorry for the confusion, I simply meant: via the allocate statement.
That is: use variables with the allocatable or pointer attribute and
use the allocate statement to allocate the memory needed for these
variables. (Automatic variables get their memory automatically - hence
my use of "explicit")

Regards,

Arjen
Permalink | Reply |
headers
Tobias Burnus | 10 Feb 13:57
Picon

Re: gfortran47, pgf90 work - ifort segfaults

Hi,

On 02/10/2012 01:45 PM, Arjen Markus wrote:
> 2012/2/10 Anton Shterenlikht<mexas <at> bristol.ac.uk>:
>> What is "explicit allocation"?
> Sorry for the confusion, I simply meant: via the allocate statement.
> That is: use variables with the allocatable or pointer attribute and
> use the allocate statement to allocate the memory needed for these
> variables. (Automatic variables get their memory automatically - hence
> my use of "explicit")

It is actually not that easy to see where memory is taken from. For 
allocatables and pointers with anonymous targets it's simple: When one 
calls ALLOCATE they are allocated on the heap.
  Similarly for variables which have the SAVE attribute: They are always 
in the static memory.

For local nonautomatic variables in procedures: If they are scalars, 
they typically are on the stack. For arrays, gfortran places them - if 
they are larger - by default in static memory. One can tune when stack 
or static memory should be used, including always static 
(-fno-automatic) and always stack (RECURSIVE, -frecursive or -fopenmp). 
(In principle, it would be also possible for the compiler to use heap 
memory.)

For temporary variables, generated by the compiler, or for automatic 
variables: gfortran either places them on the heap or (with 
-fstack-arrays) on the stack.

Thus, it is not as obvious which memory gets used. Stack memory is best:
(Continue reading)

Permalink | Reply |
headers
Steve Kargl | 10 Feb 16:26
Picon

Re: gfortran47, pgf90 work - ifort segfaults

On Fri, Feb 10, 2012 at 11:43:15AM +0000, Anton Shterenlikht wrote:
> On Fri, Feb 10, 2012 at 11:40:55AM +0100, Tobias Burnus wrote:
> > 
> > On 02/10/2012 11:08 AM, Anton Shterenlikht wrote:
> > >Intel: 12.0.2 20110112
> > >The code below segfaults only when compiled with Intel compiler.
> > 
> > The code looks valid - and using ifort 11.1, 12.0.3 and 12.1.1, it does 
> > not crash for me; thus, it could be fixed in later 12.0.x versions or 
> > might have different reasons.
> > 
> > On issue which can lead to segfaults is a too small stack. And in 
> > particular the Intel compiler uses a lot of stack space by default. 
> > Stack memory is fast - faster than memory allocated on the heap. But the 
> > down side is: By default the available stack size is rather limited. 
> > Thus, one easily runs into stack issues. Having large arrays can require 
> > a lot of stack size - exceeding the available space leads to segfaults.  
> > If ifort places "space1" on the stack, you need 31.5 MB stack space. 
> > That's not very much but might be still too much. Could you check what 
> > "ulimit -s" (POSIX shell, bash) or "limit stack" (csh, tcsh) prints?
> 
> Tobias, thanks, you are right:
> 
> % ifort z.f90 
> % limit stack
> stacksize    10240 kbytes
> % ./a.out 
> Segmentation fault
> % limit stack 100000
> % ./a.out
(Continue reading)

Permalink | Reply |

Gmane