OpenMP- No problem with parallel studio 2013(on windows).But Segmentation fault if parallel studio 2011.

[britz0907]

Hello.

I tried to generate scientific OpenMP based parallel code using previous serial code.

With parallel studio 2013+visual studio 2012, I've made successful parallel code.

However, generated code ouccurs segemation fault on linux version(parallel studio 2011).

-> forrtl: severe (174): SIGSEGV, segmentation fault occurred

I made serveral variable(type: integer, real) as a firstprivate.

Parallel studio 2013+visual studio 2012 has correct value, but parallel studio 2011 generates trash value.

[jimdempseyatthecove]

SIGSEGV is usually an indication of too small of stack (too much on specified/implicit stack). Check what conditions affect the stack capacity and either adjust them or reduce stack requirements (e.g. enable heap arrays, or explicitly allocate large arrays).

Jim Dempsey

[TimP]

Both your shell stack limit and the thread stack size (OMP_STACKSIZE) may need attention if you can't solve by -heap-arrays.

ulimit -s unlimited (if using an sh style shell) plays a role analogous to the stack size you would set in a Windows .exe.

private arrays may greatly increase both stack sizes.

[britz0907]

Thanks Jim & TimP.

Unfortunately, I've already complied using -heap-arrays tag, and checked stack size.

However, the problem is not resolved with SIGSEGV & Stack trace terminated abnormally errors.

Even if a stack size is no need adjustment(small size problem),  

Surprisingly, the program,which built by parallel studio 2011 on windows, occurs same problem.

My command lines of visual studio 2012 to bulid codes using parallel studio is 

/nologo /debug:full /O1 /Qopenmp /real_size:64 /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc110.pdb" /libs:static /threads /dbglibs /Qmkl:sequential /c

(The compile option is same both parallel studio 2011 and parallel studio 2013.)

(Errors are not occured during complie time, but 2013-> well & 2011-> not) 

[britz0907]

My ifort version 

ifort version 12.1.5 - linux

parallel studio 2013 update 1 - windows

parallel studio 2011 update 10 - windows

[jimdempseyatthecove]

What happens when you compile with OpenMP and stubs?

What happens when you compile with OpenMP (normal parallel code) and add in PROGRAM as the first parallel region:

!$OMP PARALLEL
WRITE(*,*) omp_get_thread_num()
!$OMP END PARALLEL

The above is a low stack consuming parallel region. If this runs, then suspect a resource (low stack) or coding issue (e.g. uninitialized variable). Have you compiled with gen-interfaces/warn-interfaces and full runtime checks?

Jim Dempsey

[britz0907]

Jim.

!$OMP PARALLEL
WRITE(*,*) omp_get_thread_num()
!$OMP END PARALLEL

The above region is no problem on my codes.

I believe that this problem may be related with uninitialized variable

because the codes run on very small size problem without errors.

As I mentioned, I've checked trash values( uninitialized values) occurs this problem.

I shall confirm some uninitialized values using your recommended compile tags.

Thanks.

[TimP]

It has been difficult to use the combination -check uninit -openmp.  It's good practice to have the build set up so as to be able to run without -openmp and run checks for uninitialized data.  More comprehensive advice on finding undefined data:

http://www.nas.nasa.gov/hecc/assets/pdf/training/UnInit_Fix_your_code_2012_10_31.pdf

Note that official Fortran terminology (undefined) differs from Intel's uninitialized, which applies also to icpc.

[jimdempseyatthecove]

>>It has been difficult to use the combination -check uninit -openmp.

This reminds me that one should check to see if one is using PRIVATE(X) is used when FIRSTPRIVATE(X) is intended (required) to be used.

Jim Dempsey