Fortran: segmentation fault - fortran

Question

I know I once made a similar topic, but that one was different. This time, adding a print statement does not change whether or not I get a segfault.
call omp_set_num_threads(omp_get_max_threads())
!$omp parallel do &
!$omp default(firstprivate) &
!$omp private(present_surface) &
!$omp lastprivate(fermi)
do m = 1, fourth
do n = 1, third
do j = 1, second
do i = 1, first
!current angle is phi[i,j,ii,jj]
!we have to find the current fermi surface
present_surface = 0.
do a = 1, fourth
if (angle(i,j,n,m) == angle_array(a)) then
present_surface = surface(a)
end if
end do
if (radius(i,j,n,m) >= present_surface) then
fermi(i,j,n,m) = 0.
else
fermi(i,j,n,m) = 1.
end if
end do
end do
end do
end do
!$omp end parallel do
I'm not sure about the lastprivate(fermi) statement, but it doesn't matter at this moment. shared gives the same behaviour.
So, I run this script with 'first, second, third, fourth' being increased. Typical output:
[10] Time elapsed is 0.001 [s].
[15] Time elapsed is 0.002 [s].
[20] Time elapsed is 0.005 [s].
./compile: line 2: 4310 Segmentation fault python fortran_test.py
Well, how to proceed. I looked at gdb python; run fortran_test.py, and found:
(gdb) run fortran_test.py
Starting program: /usr/bin/python fortran_test.py
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffed9b0700 (LWP 4251)]
[New Thread 0x7fffe8ba5700 (LWP 4252)]
[New Thread 0x7fffe83a4700 (LWP 4253)]
[New Thread 0x7fffe7ba3700 (LWP 4254)]
[10] Time elapsed is 0.008 [s].
[15] Time elapsed is 0.004 [s].
[20] Time elapsed is 0.005 [s].
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe7ba3700 (LWP 4254)]
0x00007fffe8dc0bb7 in __populate_MOD_fermi_integrand._omp_fn.0 () at populate.f90:31
31 do n = 1, third
If I change things in the inner loop - for instance, removing the j,i loops and putting them to a constant - then I just get the segfault at a different line.
I think this has something to do with memory, because it triggers as N increases. However, the things I've tried (export GOMP_STACKSIZE, OMP_STACKSIZE, ulimit) haven't fixed it, and I see no difference using them. (For the time being, I removed them).
Finally, the command to compile (it is in f2py):
f2py --fcompiler=gfortran --f90flags="-fopenmp -g" -lgomp -m -c populate populate.f90
As you can see, I'm quite stuck. I hope some of you know how to solve the problem.
My aim is to have N=100 run quickly (hence the openMP fortran function), but this shouldn't matter for the fortran code, should it?
If you're wondering, 4GB ram and my swap is 3.1G (Linux Swap / Solaris).
Thank you!

Answer 1

default(firstprivate) lastprivate(fermi) means that each thread receives a private copy of angle, radius, and fermi, with each being of size first x second x third x fourth. In my experience, private arrays are always allocated on the stack, even when the option to automatically turn big arrays into heap arrays is given. Your code most likely crashes because of insufficient stack space.
Instead of having everything private, you should really take a look at the data dependency and pick the correct data-sharing classes. angle, angle_array, surface, and radius are never written to, therefore they all should be shared. present_surface is being modified and should be private. fermi is written to, but never at the same location by more than one thread, therefore it should also be shared. Also, note that lastprivate won't have the expected result as it makes available the value of the corresponding variable that it has in the thread that executes the logically last iteration of the m-loop. first, second, third, and fourth are simply treated as constants and should be shared. The loop variables, of course, are private, but that is automated by the compiler.
!$omp parallel do private(present_surface)
do m = 1, fourth
do n = 1, third
do j = 1, second
do i = 1, first
!current angle is phi[i,j,ii,jj]
!we have to find the current fermi surface
present_surface = 0.
do a = 1, fourth
if (angle(i,j,n,m) == angle_array(a)) then
present_surface = surface(a)
end if
end do
if (radius(i,j,n,m) >= present_surface) then
fermi(i,j,n,m) = 0.
else
fermi(i,j,n,m) = 1.
end if
end do
end do
end do
end do
!$omp end parallel do

Answer 2

A very possible reason is the stack limit. First run ulimit -s to check the stack limit for the process. You can use ulimit -s unlimited to set it as ulimited. Then if it still crashes, try to increase the stack for OPENMP by setting OMP_STACKSIZE environmental variable to a huge value, like 100MB.
Intel has a discussion at https://software.intel.com/en-us/articles/determining-root-cause-of-sigsegv-or-sigbus-errors. It has more information of stack and heap memory.