CODEWITHSUNDEEP
optimizationsegmentation-faultfftwintel-fortran
Brick Heck
Brick Heck

Reputation: 21

SIGSEGV in optimizated ifort

If I compile with -O0 in ifort, the program can run correctly. But as long as I open the optimization option, like -O, -O3, -fast, there will be a SIGSEGV segmentation fault come out.

This error occurred in a subroutine named maketable(). And the belows are the phenomenons:

(1) I call fftw library in this subroutine. If I comment the sentences about fftw, it'll be ok. But I think it's not the fault of fftw, because I also use fftw in some other places of this code, and they are good.

(2) the fftw is called in a loop, and the loop can run several times when the program crashed. The segfault does not happen at the first time of entering the loop.

(3) I considered the stack overflow, but I don't think so now. I have the executable file complied by others long time ago, it's can be executed in my computer. I think that suggests it's not due to the system stack overflow.

The version of ifort is 10.0, of fftw is fftw-2.1.5. The cpu type is intel xeon 5130. Thanks a lot.

Upvotes: 2

Views: 951

Answers (1)

High Performance Mark
High Performance Mark

Reputation: 78316

There are two common causes of segmentation faults in Fortran programs:

  1. Attempting to access an element outside the bounds of an array.
  2. Mismatching actual and dummy arguments in a procedure call.

Both are relatively easy to find:

  1. Your compiler will have an option to generate code which performs array bounds checking at run time. Check your compiler documentation, rebuild your code and rerun it. If this is the cause of the problem you will get an error message identifying where your code goes awry.
  2. Program explicit interfaces for any subroutines and functions in your program, or use modules so that the compiler generates such interfaces for you, or use a compiler option (see the documentation) to check that argument types match at compile-time.

It's not unusual that such errors (seem to) arise only when optimisation is turned up high.

EDIT

Note that I'm not suggesting that optimisation causes the error you observe, but that it causes the error to affect the execution of your program and become evident.

It's not unknown for incorrect programs to run many times apparently without fault only for, say, recompilation with a new compiler version to create an executable which crashes every time.

Your wish to switch off optimisation only for the subroutine where the segmentation fault seems to arise is, I suggest, completely wrong-headed. I expect my programs to execute correctly at any level of optimisation (save for clear evidence of a compiler bug, such things are not unknown). I think that by turning off optimisation you are sweeping a real problem with your program under the carpet, as it were.

Upvotes: 2

Related Questions