Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
27328 Discussions

Segmentation fault (core dumped) after oneAPI HPC installed


My fortran program compiled perfectly on the Linux platform (Debian/Ubuntu) up to the Inter Fortran Compiler XA 19 compiler version. As my academic license for this compiler expired in April of this year 2021, it was no longer possible to generate a new one, so I was forced to install the oneAPI Base & HPC Toolkit products, which contain the new Fotran compiler. From then on, my program compiles, but running it started throwing the following error "Segmentation Fault (core dumped)". It's been months and I can't understand the cause of this error.
1. I urgently need a new license for the old version of the compiler (19). How to get it?
2. Otherwise, what exactly has changed in this new version (oneAPI) of the Fortran compiler?
3. What do I need to do in my code to investigate probable causes of this error?
4. I've already searched for many references and included many directives in the compilation line, but to no avail.
I really appreciate any help or cooperation.

Labels (2)
0 Kudos
9 Replies
Black Belt Retired Employee

There are uncountable possible reasons for this. The basic answer is that a segmentation fault (segfault), which on Windows is "access violation", occurs when an instruction attempts to access an invalid memory address (for example, zero.) Asking "exactly what changed" is not helpful.

I'll tell you how I would track down such problems (I did this for almost 40 years doing compiler support). First, I take the command line options used to compile and start removing them until I get the minimum set that still shows the problem. If -O (optimize) is still there, I'll reduce the level to see if I still get the issue at -O0.  

When I have identified the one option, if removed or changed, changes the behavior, I'll experiment with using different options on different sources, seeing if I can identify one source which, when the options are changed, triggers the error.

Next I'll enable traceback or, if possible, run the program under the debugger. The goal is to find which statement triggered the error.  Then I might add diagnostic options such as bounds and shape checking to see if I am corrupting memory somewhere. 

It's unusual (but not unheard of) for a compiler change to introduce a problem such as this. Most often I found that the program had an error, but the error did not show itself when compiled with the older compiler.

After that, one starts stripping away parts of the program that aren't needed to show the error to get a minimal but working reproducible example.


I thank you for your attention. I believe the problem is in my code, but for some reason the previous version of the compiler didn't identify it. And this current version must be stricter. That's why I would like to read some "release notes" of the new compiler version.

New Contributor I

A segfault occurs when a reference to a variable falls outside the segment where that variable resides, or when a write is attempted to a location that is in a read-only segment. In practice, segfaults are almost always due to trying to read or write a non-existent array element, not properly defining a pointer before using it, or (in C programs) accidentally using a variable's value as an address (see the scanf example below).


Some of my very old Fortran programs caused this type of problem because I was writing to one past the end of the array, in the old days this did not necessarily matter, but new compilers catch old sins.  I had one a few weeks ago, it does not take long to track down - just follow the Steve notes, like the Cliff Notes, but usually better. 

Black Belt

The compiler has options to perform interface checking (and generation for older style programs) as well as options to enable various runtime checking (such as checking for use of uninitialized variables, and indexing our of bounds). It is not unusual to fine out that for programs that used to run OK before and that now fail had a programming error that was asymptomatic (gave or was assumed to give correct results).

Jim Dempsey


Thank you once again for the help posted so far. An important fact that I haven't written yet is that this same fortran code compiles and runs correctly (without errors) on the windows platform. After using the new compiler (oneAPI HPC Toolkit) this Segmentation Fault problem started to occur only on the Linux platform.

Valued Contributor III

As others have said already, it is very likely that there is a bug in your program that is causing this. I have seen memory errors pop up under Linux that were not visible on Windows. Have you tried tools like valgrind and Intel Inspector to identify possible memory problems?

Valued Contributor II

Even moving simple programs from Windows to LINUX can run into interesting problems.  I spent 6 months once on what should have been trivial and in the end just gave up. 


compile with -g -traceback and run.  that will hopefully identify the line number of the fault.

Before you run

ulimit -s unlimited

assuming you use bash as your shell.