topic Both your shell stack limit in Intel® Fortran Compiler

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

britz0907 — Mon, 02 Sep 2013 08:59:47 GMT

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.

SIGSEGV is usually an

jimdempseyatthecove — Mon, 02 Sep 2013 12:39:16 GMT

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

Both your shell stack limit

TimP — Mon, 02 Sep 2013 13:07:30 GMT

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.

Thanks Jim & TimP.

britz0907 — Mon, 02 Sep 2013 13:45:49 GMT

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)

Thanks Jim & TimP.

britz0907 — Mon, 02 Sep 2013 13:46:00 GMT

My ifort version

ifort version 12.1.5 - linux

parallel studio 2013 update 1 - windows

parallel studio 2011 update 10 - windows

What happens when you compile

jimdempseyatthecove — Tue, 03 Sep 2013 12:48:20 GMT

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

Jim.

britz0907 — Tue, 03 Sep 2013 13:23:39 GMT

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.

It has been difficult to use

TimP — Tue, 03 Sep 2013 14:41:58 GMT

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.

>>It has been difficult to

jimdempseyatthecove — Tue, 03 Sep 2013 21:25:20 GMT

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