severe (174): SIGSEGV and Stack trace terminated abnormally

severe (174): SIGSEGV and Stack trace terminated abnormally

Hi All,

I got the following fault in segmentation when I was using ifort to compile the code with terminal in Mc OS*X.

Time=160554.300
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image                      PC                        Routine         Line                    Source
a.out            00000001053A02A6         Unknown       Unknown              Unknown
a.out            00000001053895F6          Unknown       Unknown              Unknown
a.out            0000000105388F0C         Unknown       Unknown              Unknown
libdyld.dylib  00007FFF8A7897E1        Unknown       Unknown              Unknown

I have followed the article http://software.intel.com/en-us/articles/determining-root-cause-of-sigsegv-or-sigbus-errors Determining Root Cause of Segmentation Faults SIGSEGV or SIGBUS errors

When the first solution ifort -heap-arrays doesn't help.

Since the stacksize in Mac OS*X cannot be unlimited.

I tried the third solution, -O2 -g -traceback, and here below is the output I got,

587228364:~ user$ ifort -O2 -g -traceback /Users/UMICH/Desktop/code_73_5.f
587228364:~ user$ ./a.out
Time=160829.037
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source

Stack trace terminated abnormally.

I think "Stack trace terminated abnormally" is the problem for compiling. Can anyone give me any suggestions on the next step? Thanks!

12 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

Did you try the first solution or just dismiss it because of the stack size?  The -heap-arrays option allocates your automatic arrays on the heap and not the stack, reducing your stack usage, not increasing it.  I meniton this because it seems you might have it mixed up based on your comment -- you can either use -heap-arrays or set stacksize unlimited, one or the other is needed, not both.

If you compile and -heap-arrays does not fix your problem, you can also try "-check bounds" to see if you are indexing an array out of bounds and corrupting your stack.  For any help beyond that, it would he helpful to see the fortran code you are compiling.

The "stack trace terminated abnormally" often means that you have corrupted the stack through an out-of-bounds access.  Try also building with "-warn interface" - it may find a problem.

Steve - Intel Developer Support

Since compile time warnings do not effect the instructions which are produced by the compiler, as far as I know, I recomend always building with -warn. It helps you catch a ton of stuff. Also, the runtime checking is pretty good too, you can enable all checks with "-check." Be wary, however, that "-check uninit" only will catch certain cases.

-Zaak

Hi Everyone, thanks for your commends and I found Steve's advice-warn interface helped me to get the errors instead of segmentation fault. Here in the attachment is my code and can you help me to take a look at it? Thanks!

Fichiers joints: 

Fichier attachéTaille
Télécharger code-73-5.f.zip12.82 Ko

You are passing double precision 1.0 and 0.0 to arguments declared as real*16 (quad precision). This will cause wrong values. Change these to 1.0_16 and 0.0_16. (or 1.0Q0 and 0.0Q0, extensions, but so is the real*16 syntax.

Steve - Intel Developer Support

Hi Steve, thanks for your reply and I think I have fixed up the problem of double precision now. However, when I'm compiling the code, another kind of error said,

/Users/Desktop/code_73_5.f(496): error #6410: This name has not been declared as an array or a function. [A]
A(j,i,m)=0.d0

I think I have declared the code in line 487, as you can see in my code(attached in the previous reply): 

real*16 A(nj,id,id),B(nj,id,id),D(nj,id,id),X(nj,id,id), Y(nj,id,id),act_coe(nj)

I've been thinking of this problem for one week and couldn't figure out why. Could you help me to take a look at it? Thanks so much!

The line numbers in your latest post probably do not match the line numbers in the code that you posted earlier after you applied the modifications. Please post the actual source code that corresponds to the reported compile-time error.

Hi mecej4, thanks for your attention and here in the attachment is my original source file, which occurs with the compile-time error. Thanks in advance!

Fichiers joints: 

Fichier attachéTaille
Télécharger code-73-5.f.zip12.82 Ko

Your code has a number of errors.

Compiling with /warn:all will tell you about inconsistent argument types in the calls to meshpt and write_out.

There are numerous instances of array subscript violations, which you can detect by using the /check option. The allocated size of array parameters is too small. There may be one or more elements of pre_C that are used in expressions before they have been assigned values.

After correcting these errors you will still need to examine whether the program contains a correctly implemented algorithm.

Hi All, thanks for your help and I used -warn all to show all the errors, warnings and remarks. Now I have corrected errors regarding the argument inconsistency in "meshpt", but I have encountered with another serious problem:

error #5508: Declaration of routine 'MESHPT' conflicts with a previous declaration
subroutine meshpt(array,a,b,num,step)

I know it's a bug from compiler but I don't know how to remove the compile options of -warn interface in Mac *OX terminal with ifort. Here in attachment is the latest version of code. Could you help me to take a look at it? Thanks! 

Fichiers joints: 

Fichier attachéTaille
Télécharger code-73-5-10282013.f.zip12.9 Ko

Why would you want to remove the option to check interfaces, when your code still has errors in that regard? Ignoring errors is not going to make them disappears. You have to examine and correct your source code.

As I stated earlier, the code has numerous errors in addition to mismatched arguments to meshpt and write_out. I find  inconsistent 3-d array declarations and uninitialized variables, as well.

I have a suspicion that you have used real*16 throughout your code without justification.

Laisser un commentaire

Veuillez ouvrir une session pour ajouter un commentaire. Pas encore membre ? Rejoignez-nous dès aujourd’hui