Severe fortll (174): segmentation fault ocurred

[postaquestion]

I've been experience a run-time error that states "severe fortll (174): segmentation fault ocurred" every time one program of mine tries to open and write an output file. I have tried to handle this error by transfering control to ERR branch specifiers and IOSTAT specifier in I/O statements. I have experimented the control transfer in the OPEN, WRITE and CLOSE commands, but even so the run-time error message persists. I'm using a Linux Red Hat 9.0 platform.

[Steven_L_Intel1]

segmentation fault is not an I/O error, so you can't redirect it with IOSTAT or ERR=. You may find this article., which I wrote about Windows (and pre-Intel) but still relevant, informative. Access Violation is the Windows equivalent of Segmentation Fault.

You may want to try -heap-arrays and see if that helps. If you're writing a large array expression, it might require a large stack temp.

[carlos_asarf]

Let me give you some more informations about my code arrangement...

The code i have developed in fortran90 is a seismic migration procedure that transforms a input matrix with dimensions (nt,ntrace) -- seismic data in the time domain -- to a output matrix in depth (nz,nx), where nt, nx, nz are integers numbers of the dimensions of each array.

This program compiles fine, but i got the segmentation fault error-message when it tries to write to file the last 2 files -- the 5 previousfiles are successfully formatted-written to file.

I have tracked the code for errors such as double x single precision assignment (although i have defined them all in a separated module), input of wrong arguments, uninitialized address, etc, but the error message persists. The program compiles fine: i input a header file with several parameters and the names of the output files (character arrays), and it runs accordingly (it goes through several subroutines), but it abruptly ends with an exception (the so called segmentation fault) while writing the last 2 matrices -- by the way, the most important ones. I have also checked for array allocation an bounds, but none of these itensare in error. I have also debugged the whole code and no errors were found.

Please, i need a help...

Sincerely,

Carlos

[Ron_Green]

Please confirm that you:

1) compile with 'ifort -heap-arrays ...'

2) before you run, enter:
ulimit -s unlimited

ron

[carlos_asarf]

You mean "ifort -heap-arrays ulimit -s unlimited"?

Carlos

[Ron_Green]

no,

ifort -heap-arrays

along with any other options such as -O3

Then, let us say that your executable is named 'a.out'. Before you run a.out, do this from the command line:

ulimit -s unlimited

./a.out

The ulimit is a command to set your bash shell stack limit to unlimited.

ron

[carlos_asarf]

Ron,

It did not work out. The command ulimit -s unlimitedsends a "command not found" message in response.

Thank you anyway.

C.

[Ron_Green]

I see. You must have csh or tcsh as your user shell. You can test this by:

echo $0
^ this is a zero

which should return:
csh
or
tcsh

The equivalent command for csh or tcsh is:

limit stacksize unlimited

BUT, I would prefer that you try to compile with 'ifort -heap-arrays ' first.

If your code still has a segmentation fault, then try these ifort options:

ifort -g -traceback -check all -heap-arrays

ron

[carlos_asarf]

ron,

I have implemented all your suggestions, but it didn't work out. Is there any other solution to the problem?

C.

[Ron_Green]

I just have one last test for you. Use these ifort compiler options:

ifort -g -traceback -check all -fp-stack-check

Now run the code. You will get the segmentation fault. But you should have a stack traceback. In that, it should have the sourcefile and line number where the segmentation fault occurs. Cut and paste that stack trace so I can see that.

Also, if you have the source file and line number of the write statement that is failing, put that write statement into this issue so I can have a look.

[carlos_asarf]

Ok, ron.

These are the sequences of stacks i obtained after following your latest instructions:

(1) First stack traceback

forrtl: warning (402): fort: (1): In call to DYNRAY_GRAD, an array temporary was created for argument #1

(2) Second stack traceback

forrtl: severe (408): fort: (3): Subscript #2 of the array T has value 0 which is less than the lower bound of 1

Image PC Routine Line Source

migra.x 00000000004CE882 Unknown Unknown Unknown

migra.x 00000000004CDA7E Unknown Unknown Unknown

migra.x 0000000000487986 Unknown Unknown Unknown

migra.x 0000000000465BC2 Unknown Unknown Unknown

migra.x 0000000000464B48 Unknown Unknown Unknown

migra.x 0000000000460C3F initial_ 124 Eik_difrac.f

migra.x 000000000044BAF6 eikonal_ 32 Eik_difrac.f

migra.x 0000000000404431 migrate_beam_grad 337 beampara.f90

migra.x 000000000043EF31 MAIN__ 248 Programa.f90

migra.x 0000000000403262 Unknown Unknown Unknown

libc.so.6 0000003691B1C4BB Unknown Unknown Unknown

migra.x 00000000004031AA Unknown Unknown Unknown

(3) The itens (1) and (2) normally do not appear while in normal running, without compiling for stack traceback. In fact the segmentation fault message error occurs here (indicate by an arrow):

print*,5

open(26,file=fname3,status='replace',action='write') <------------------

write(26,'(e10.3)') ((real(migd(iz,ix)),iz=1,nz_mig),ix=1,nx_mig) <------------------

close(26)

print*,7

open(20,file=fname4,status='replace',action='write')

do ix=1,nx_mig

write(20,'(e10.3)')(real(modelmig(iz,ix)),iz=1,nz_mig)

end do

close(20)

Since it does not write to fname3, consequently it does not write to fname4. So the program stops abnormally where indicated by the arrow.

(4) I have checked lines 248, 337, 32 and 124 in each of the subroutines listed, but have found no apparent errors. As I mentioned, the stacks in (1) and (2) appear only if i compile the source (main) code with the instructions you have told me to do. In normal compilation, without tracebacks, these errors do not appear. The error seems to be in the writing option. But this, i don't know why.

(5) migra.x is the executable file. But what is libc.so.6??

(6) Last comment: my variables are all double precision. Is there a problem in this choice?

Should i write a new code? :)

[TimP]

Your bounds check has told you that an out of bounds array reference has occurred. This, or a similar occurrence later on, would likely be responsible for the segfault. There is no code to catch this until you set the check bounds compile option, but the out of bounds reference would still be likely to produce bad results. You would have to correct the out of bounds references one at a time, to eliminate this probable cause of your failure.

Running under debugger may make it easier to find out which array reference is out of bounds.

libc.so.6 is probably not the cause of your failure; if out of bounds references are diagnosed, the problem is in your source code. libc would be used for some run-time functions. It could show a failure if you passed a bad reference to it.

Double precision is a problem only in that out of bounds references may cause a crash sooner than single precision. Changing precision would not correct it.

[carlos_asarf]

Ok, thanks, Ron.

I will check for the bounds. I tell you later the results.

C.