Segmentation fault with reshape function

[kokkola]

Hello,

An atmospheric circulation model which I am using gives a segmentation fault when reshape function is used. I am using a computer with eight Opteron 64 dual core processors, and Intel 10.1.011 compiler. The bug in the model can be reproduced using the following routines:

main.f90

PROGRAM main4
USE mo_shaper
IMPLICIT NONE
INTEGER, PARAMETER :: dp = SELECTED_REAL_KIND(12,307)
REAL(dp) :: x(61, 201, 101),x2(61, 201, 101)
INTEGER, DIMENSION(3) :: a
x=1.
a=shape(x)
call shaper(x,x2,a)
END PROGRAM main4

and mo_shaper.f90

MODULE mo_shaper
CONTAINS
SUBROUTINE SHAPER(x,x2,a)
IMPLICIT NONE
INTEGER, PARAMETER :: dp = SELECTED_REAL_KIND(12,307)
REAL(dp) :: x(:,:,:),x2(:,:,:)
INTEGER :: a(3)
x2=reshape(x,a,order=(/1,2,3/))
END SUBROUTINE SHAPER
END MODULE mo_shaper

Compiling and running these will end up in segmentation fault. This can be avoided by using -heap-arrays flag, but then the circulation model hogs up all the memory (32G) and crashes the whole system. I can run the same model on my desktop with no problem using other compilers, but on that eight processor machine Intel is all we have. The above example compiles and runs with no problem using gfortran, g95, Absoft, PGI, Lahey-Fujitsu, Sun, NAG and some Inter 9.xx version (though, not all 9-versions) compilers. Also, the circulation model runs well on the eight processor machine with Lahey-Fujitsu trial version. So, to me it seems, that there is something wrong with the Intel 10-series compilers.

[TimP]

A few points seem to be missing from your discourse.
If you are using OpenMP on this machine, you may have to set a higher than default value in KMP_STACKSIZE. The default value is lower on 32-bit compilation. It's not the CPU model which matters, it's whether you use the 32- or 64-bit compiler. It's safer to avoid abbreviations:
set KMP_STACKSIZE=6000000
rather than 6m, even though the latter is supposed to be supported.
Depending on the details of your code, running more threads may be increasing memory consumption, so 32GB may not be enough for 16 threads, when 4GB may work for 1 thread.
If you aren't using OpenMP, it's still possible, particularly on a 32-bit OS, that you may have to set a stack limit explicitly. Some compilers might do it behind the scenes.

[kokkola]

I am using the 64-bit compiler and MPICH2, not OpenMP. On NEC-SX6, 24 GB has been enough to run the model on 8 processors.

But I am also curious, why my example program gives the segmentation fault on every machine and nearly every Intel compiler version I've tried. The code basically doesn't even do anything.

[jimdempseyatthecove]

Can you try adding SAVE to make the array persistent?

REAL(dp), SAVE:: x(61, 201, 101),x2(61, 201, 101)

This will eat up about 20MB of static data but at least it won't walk all over your virtual addres space as would heap arrays. This might give you a work around to get you going on your 16-way system.

Jim Dempsey