forrtl: severe (174): SIGSEGV, segmentation fault occurred

forrtl: severe (174): SIGSEGV, segmentation fault occurred

Hi All,

I get the following error as I run my code.

forrtl: severe (174): SIGSEGV, segmentation fault occurred

I was wondering if anyone knows what is the source of this error!

Thanks in advance!

Sarvin

29 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

As Steve said, segmentation violations can come from many many things.

80% of the time, simply increasing your stacksize fixes the problem. OR just compile with

-heap-arrays

that takes care of 80% of the cases.

Next, isolate the fault with a stack traceback

-O2 (or -O3) -g -traceback

on both compile and link.

Yes, you can add -g to get symbolic information on optimized code as long as you also include a -Ox option.

Next, make sure you're not doing something silly in your code (array bounds violations, for example)

...other options... -g -traceback -check all -fp-stack-check

That finds 99% of these. The remaining 1%, possible compiler bug. Tar up the code, open a problem report at premier.intel.com, attach the file, include instructions on how to build and run.

ron

There are infinite possibilities. Two articles I wrote for Windows Fortran would also be instructive for you. These cover Access Violation (SEGV on Linux) and Stack Overflow. On Linux, you can try raising the stack limit with "ulimit -s" or "limit stacksizae unlimited" depending on your shell.

The key to identifying the cause is to find exactly WHERE in your program this error is occurring. Use of -traceback can help here.

Steve

I have the exact same error with RJ LeVeque's CLAWPACK software:

http://www.amath.washington.edu/~claw/

which is pretty benign code.

switching to the fce, as opposed to the fc distribution, which I understand to be the 64 bit version eliminates this error. It'd be great to understand why though.

Thanks for the fc versus fce tip. I'm running on an Intel 64-bit MacPro running Leopard OSX 10.5.2 and this solved my segmentation fault problem.

-Jason

Quoting - aufded93@erau.edu
Thanks for the fc versus fce tip. I'm running on an Intel 64-bit MacPro running Leopard OSX 10.5.2 and this solved my segmentation fault problem.

-Jason

Hi,

I'm running on the same machine(Macbook Pro), however I still have the same problems.

:

:

soil water balance error @ 1990 365 23 30
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
runclass 000000010005EAC7 Unknown Unknown Unknown
runclass 000000010005DDA9 Unknown Unknown Unknown
runclass 00000001000009BC Unknown Unknown Unknown
runclass 0000000100000954 Unknown Unknown Unknown
CNCALASS cks$

Could you show me a right direction? Thanks.

I'm just wondering that the Makefile did not allocate the memory, but I do not know how to convert the Makefile for IBM Fortran Compiler to Intel Fortran Compiler. (The original Makefile was build for the programs I'm trying to run under Intel Fortran Compiler!)

====

.SUFFIXES : .f .o

FC=xlf90

FFLAGS= -q64 -O0 -qrealsize=8 -qintsize=8 -qsave -qspillsize=32648

:
:
:
====

In my case of the segmentation fault, it helped me to increase the stack size using "ulimit -s unlimited". I am using Intel Fortran 11.0.069 on Kubuntu 8.04.

Quoting - jirina

In my case of the segmentation fault, it helped me to increase the stack size using "ulimit -s unlimited". I am using Intel Fortran 11.0.069 on Kubuntu 8.04.

Where did you put "ulimit -s unlimited"? In the Makefile?

I used that command in the shell (console) before running my application.

Using the SYSTEM function from IFPORT to send a command to the shell would not help in this case, because the command is executed in a separate shell and does not affect the shell which the application is running in.

I am running Kubuntu 8.04 and if I want to have certain settings for each shell I start, I add the corresponding commands at the end of the file .bashrc in the home directory. E.g., I have this:

# set up environment for Intel Fortran

source /opt/intel/Compiler/11.0/069/bin/ifortvars.sh ia32

# set unlimited stack size

ulimit -s unlimited

Is that possible the error generated because of the program contains "rand()" function?

Here is another previous post.

http://software.intel.com/en-us/articles/intel-fortran-compiler-using-ra...

In the source code, program uses the rand() function to randomly choose the meteorological files for rewinding files.

:

:

!-----pre-running meteorological data

open(unit=41,file="TP39_met03_class.dat")

open(unit=42,file="TP39_met04_class.dat")

open(unit=43,file="TP39_met05_class.dat")

open(unit=44,file="TP39_met06_class.dat")

open(unit=45,file="TP39_met07_class.dat")

:

:

idfile = 40+int(rand()*4+1) !open file id = 41,42

rewind(unit=idfile) !rewinding the file to the first line

print *,iyear,idfile !for checking purpose

endif

Quoting - kchang@uoguelphca

Is that possible the error generated because of the program contains "rand()" function?

idfile = 40+int(rand()*4+1) !open file id = 41,42

That looks strange, but you're right, it requires the addition of the corresponding interface block, e.g. by USE IFPORT, as the empty argument is broken without interface definition.

Quoting - moghaddam@umbi.umd.edu

Hi All,

I get the following error as I run my code.

forrtl: severe (174): SIGSEGV, segmentation fault occurred

I was wondering if anyone knows what is the source of this error!

Thanks in advance!

Sarvin

I have found that if I compile with NO optimization (ifort -O0 file.f), then I no longer get SEGV.
There must be a bug in the compiler - I have narrowed down the place where the SEGV occurs to
a little loop in a table-lookup subroutine that should NEVER NEVER be vectorized.

Of course the resulting compiled program runs no faster than what I get on a 3.5 year old Linux workstation.

Cheers.

Quoting - Steve Lionel (Intel)
There are infinite possibilities. Two articles I wrote for Windows Fortran would also be instructive for you. These cover Access Violation (SEGV on Linux) and Stack Overflow. On Linux, you can try raising the stack limit with "ulimit -s" or "limit stacksizae unlimited" depending on your shell.

The key to identifying the cause is to find exactly WHERE in your program this error is occurring. Use of -traceback can help here.

Where could I find the two articles (Access Violation and Stack Overflow)?

Thanks,
Randi

New forum links: Access Violation and Stack Overflow

Steve

Hi Jirina,

I noticed that you had a same error before as what I have now. The error am having now as follow :
Any thoughts how tio fix this problem? Many thanks in advance yeah. Regards.

Namelist dfi_control not found in namelist.input. Using registry defaults for v
ariables in dfi_control
Namelist tc not found in namelist.input. Using registry defaults for variables
in tc
Namelist scm not found in namelist.input. Using registry defaults for variables
in scm
Namelist fire not found in namelist.input. Using registry defaults for variable
s in fire
REAL_EM V3.1.1 PREPROCESSOR
*************************************
Parent domain
ids,ide,jds,jde 1 74 1 61
ims,ime,jms,jme -4 79 -4 66
ips,ipe,jps,jpe 1 74 1 61
*************************************
DYNAMICS OPTION: Eulerian Mass Coordinate
alloc_space_field: domain 1, 98642504 bytes allocated
Time period # 1 to process = 1996-01-01_00:00:00.
Time period # 2 to process = 1996-01-01_06:00:00.
Time period # 3 to process = 1996-01-01_12:00:00.
Time period # 4 to process = 1996-01-01_18:00:00.
Time period # 5 to process = 1996-01-02_00:00:00.
Time period # 6 to process = 1996-01-02_06:00:00.
Time period # 7 to process = 1996-01-02_12:00:00.
Time period # 8 to process = 1996-01-02_18:00:00.
Time period # 9 to process = 1996-01-03_00:00:00.
Time period # 10 to process = 1996-01-03_06:00:00.
Time period # 11 to process = 1996-01-03_12:00:00.
Time period # 12 to process = 1996-01-03_18:00:00.
Time period # 13 to process = 1996-01-04_00:00:00.
Time period # 14 to process = 1996-01-04_06:00:00.
Time period # 15 to process = 1996-01-04_12:00:00.
Time period # 16 to process = 1996-01-04_18:00:00.
Time period # 17 to process = 1996-01-05_00:00:00.
Time period # 18 to process = 1996-01-05_06:00:00.
Time period # 19 to process = 1996-01-05_12:00:00.
Time period # 20 to process = 1996-01-05_18:00:00.
Time period # 21 to process = 1996-01-06_00:00:00.
Time period # 22 to process = 1996-01-06_06:00:00.
Time period # 23 to process = 1996-01-06_12:00:00.
Time period # 24 to process = 1996-01-06_18:00:00.
Time period # 25 to process = 1996-01-07_00:00:00.
Time period # 26 to process = 1996-01-07_06:00:00.
Time period # 27 to process = 1996-01-07_12:00:00.
Time period # 28 to process = 1996-01-07_18:00:00.
Total analysis times to input = 28.
-----------------------------------------------------------------------------
Domain 1: Current date being processed: 1996-01-01_00:00:00.0000, which is loop # 1 out of 28
configflags%julyr, %julday, %gmt: 1996 1 0.0000000E+00
d01 1996-01-01_00:00:00 Timing for input 0 s.
Converged znw(kte) should be about 0.0 = -2.0489097E-08
d01 1996-01-01_00:00:00 Old data, no inland lake information
LAND CHANGE = 0
WATER CHANGE = 0
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
real.exe 080979AC Unknown Unknown Unknown
real.exe 08067164 Unknown Unknown Unknown
real.exe 0804BAF7 Unknown Unknown Unknown
real.exe 0804AC7B Unknown Unknown Unknown
real.exe 0804A8F1 Unknown Unknown Unknown
libc.so.6 005C2E9C Unknown Unknown Unknown
real.exe 0804A801 Unknown Unknown Unknown
[ceambi@cen-mm5-dev2 run]$

ceambi,

This error message has many possible causes. Please read Diagnosing SIGSEGV Errors.

Steve

I got segmentation fault when I increased some array sizes in my code. I tried using -traceback, but it did not help.

As recommended in this thread, I set 'ulimit -s unlimited' and I got rid of the segmentation faults.

Thanks to you guys,

Syed

What do you mean by fce or fc?

Hello Steve

I can not find any link about 'Access Vilation' and 'Stack Overflow' in the page you give.

and

can you tell me how to use -traceback to do this job?

thanks,
alex

In past versions, the name of the compiler was fc or fce, both replaced quite a while ago by ifort.

Look up the compiler options. Add -traceback to the compile and link options. You may need to run under idb idbc or gdb (and use the bt command after crash). This should show which of your subroutines was running at the time of the crash. Then you could set a breakpoint ahead of the crash point, run up to it, and investigate what is going wrong. Needless to say, it may be easier to take care of stack size issues and those which will be found by compiler diagnostics before trying to step up to the crash.

Alex,

"access violation" is a Windows error - the Linux equivalent is Segmentation Fault (also known as SEGV). Which OS are you on?

Adding -traceback will give you the source file name and line number where the error occurred. What error are you seeing?

Steve

Quoting Alex AdamsHello Steve

I can not find any link about 'Access Vilation' and 'Stack Overflow' in the page you give.

and

can you tell me how to use -traceback to do this job?

thanks,
alex

Dear Steve

I came across such problems when I use OPENMP in my fortran90 scripts on the platform Linux:
the compile is done by ' ifort -o runscript *.f90-openmp' and run by ' ./runscript'

the basic thought why I apply OPENMP to my scripts is to improve the efficiency of the time-consuming DO loop in my program. such as

!$OMP PARALLEL DO &
!$OMP DEFAULT(SHARED) &
!$OMP PRIVATE(COSRAD,FGCSRAD,FBCSRAD,LATD,LONGD,UTCT,P,PCS,K,II,JJ,KK,MJT1,MJT2,MJT,NEWSTEC,NEWVTEC,VTECRMS,OLDSTEC,WT,YG,FACT1,FACT2,snindex)
!! here variables[scalars& arrays ie. P(32),PCS(256)]declared in PRIVATE directive is the temporary resultcomputed in the do loopand all the other variables used in do loop is the ones defined outside do loop( most of them are arrays)
Do inum = 1, totalnum !! here totalnum is maybe 20000000

cosrad = 2.0*zld(inum) !!zld is the array which not only used inside the doloop but used in the outside

if(numdex == 0) goto 118

call computev(cosrad,fgcsrad,fbcsrad,latd,longd,utct,pcs,mjt1,mjt2,mjt,newstec,newvtec,vtecrms,snindex)
!!this subroutine is for computation with dummy input 'cosrad,fgcsrad,fbcsrad,latd,longd,utct,pcs,mjt1,mjt2,mjt,snindex' and output 'newstec,newvtec,vtecrms'.

118call computevv(p,pcs,wt,yg,work(i1),work(i2),work(i3)) !!here work is an array defined outside the doloop

enddo
!$OMP END PARALLEL DO

for the upper doloop, I compiled it and run it, but the problem came up:


forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
libpthread.so.0 00007F7863F699CB Unknown Unknown Unknown
libiomp5.so 00007F786449E2A8 Unknown Unknown Unknown

I used the following method to attempt to solve my problem:
ulimit -s unlimited
export OMP_STACKSIZE=1000M
all above is useless, the I used export OMP_NUM_THREADS=1 to test in single thread, but the same problem came up again.
I can not find solution about this problem futher more, can you give me some help ?
thanks
yours alex

PS:this program is runned well in serial means

It looks as if you need to explore more of the suggestions posted at the top of this forum. Your request for help would be much more effective if you would describe what you learned by following those steps.
Your statement is contradictory in that you say your application works fine in serial mode but not when running a single thread. If you mean that it breaks when you switch to options which support threading, a possibility is that you have failed to declare a local array with SAVE where you are depending on that behavior.

Hi Timp,

I use a debugger and it give me the information like this:

forrtl: severe (408): fort: (8): Attempt to fetch from allocatable variable P when it is not allocated

Image PC Routine Line Source
ionmond 00000000004DE531 Unknown Unknown Unknown
ionmond 00000000004DD505 Unknown Unknown Unknown
ionmond 00000000004965EA Unknown Unknown Unknown
ionmond 0000000000455675 Unknown Unknown Unknown
ionmond 00000000004544CE Unknown Unknown Unknown
ionmond 00000000004210ED ionsol_ 177 IONSOL.f90
libiomp5.so 00002AF3D9D67ED3 Unknown Unknown Unknown

what I do :
I allocate P(32,32) and pcs(200) outside the openmp parallel region, but I want to use them by each thread, so I declare :

allocate(p(32,32))
allocate(pcs(200))

!$omp parallel do default(shared) private(p,pcs, otherscalars)
do i = 1, numline
p = 0.d0
pcs = 0.d0
otherscalars = 0.d0
.....

enddo
!$omp end parallel do

deallocate(p,pcs)

and then I triedanother modificationtomy scripts like :

!$omp parallel do default(shared) private(p,pcs, otherscalars)
do i = 1, numline
allocate(p(32,32))
allocate(pcs(200))
p = 0.d0
pcs = 0.d0
otherscalars = 0.d0
.....
deallocate(p,pcs)
enddo
!$omp end parallel do

it also give me error information!

I am confused with this situation , I just want the use p and pcs arrays by each thread as local variables, but I can not make it. can you give me some suggestions about how to do it?

>>computev(cosrad,fgcsrad,fbcsrad,latd,longd,utct,pcs,mjt1,mjt2,mjt,newstec,newvtec,vtecrms,snindex)

Which values get modified by computev?

>>computevv(p,pcs,wt,yg,work(i1),work(i2),work(i3))

Which values get modified by computevv?

Of the values modified bycomputev andcomputevv which are accumulative?
Of the values modified bycomputev andcomputevv which are totally independent on each iteration?
(i.e. are scratch temporaries who's values are meaningless between iterations of inum.)

>>PS:this program is runned well in serial means

By this do you mean by omitting the compiler switch to process the OpenMP directives?
(or do you mean by running the program prior to editing it for use with OpenMP?)

Jim Dempsey

www.quickthreadprogramming.com

I got the following error when I run my code

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC        Routine            Line        Source             
univ               0804A84E  Unknown               Unknown  Unknown
univ               08049DD7  Unknown               Unknown  Unknown
libc.so.6          B75384D3  Unknown               Unknown  Unknown
*** glibc detected *** ./univ: double free or corruption (!prev): 0x08a12208 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x75ee2)[0xb7594ee2]
./univ[0x805e86b]
./univ[0x804b92a]
./univ[0x804f436]
./univ[0x804cd6c]
./univ[0x804f87f]
[0xb772440c]
./univ[0x8049dd7]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb75384d3]
======= Memory map: ========
08048000-080c3000 r-xp 00000000 08:05 6029869    /home/mamadou/Documents/univ
080c3000-080c8000 rw-p 0007a000 08:05 6029869    /home/mamadou/Documents/univ
080c8000-080cc000 rw-p 00000000 00:00 0
08a0f000-08a30000 rw-p 00000000 00:00 0          [heap]
b74fb000-b74fc000 rw-p 00000000 00:00 0
b74fc000-b74ff000 r-xp 00000000 08:05 131983     /lib/i386-linux-gnu/libdl-2.15.so
b74ff000-b7500000 r--p 00002000 08:05 131983     /lib/i386-linux-gnu/libdl-2.15.so
b7500000-b7501000 rw-p 00003000 08:05 131983     /lib/i386-linux-gnu/libdl-2.15.so
b7501000-b751d000 r-xp 00000000 08:05 131991     /lib/i386-linux-gnu/libgcc_s.so.1
b751d000-b751e000 r--p 0001b000 08:05 131991     /lib/i386-linux-gnu/libgcc_s.so.1
b751e000-b751f000 rw-p 0001c000 08:05 131991     /lib/i386-linux-gnu/libgcc_s.so.1
b751f000-b76c2000 r-xp 00000000 08:05 131970     /lib/i386-linux-gnu/libc-2.15.so
b76c2000-b76c4000 r--p 001a3000 08:05 131970     /lib/i386-linux-gnu/libc-2.15.so
b76c4000-b76c5000 rw-p 001a5000 08:05 131970     /lib/i386-linux-gnu/libc-2.15.so
b76c5000-b76c9000 rw-p 00000000 00:00 0
b76c9000-b76e0000 r-xp 00000000 08:05 132050     /lib/i386-linux-gnu/libpthread-2.15.so
b76e0000-b76e1000 r--p 00016000 08:05 132050     /lib/i386-linux-gnu/libpthread-2.15.so
b76e1000-b76e2000 rw-p 00017000 08:05 132050     /lib/i386-linux-gnu/libpthread-2.15.so
b76e2000-b76e4000 rw-p 00000000 00:00 0
b76e4000-b770e000 r-xp 00000000 08:05 132002     /lib/i386-linux-gnu/libm-2.15.so
b770e000-b770f000 r--p 00029000 08:05 132002     /lib/i386-linux-gnu/libm-2.15.so
b770f000-b7710000 rw-p 0002a000 08:05 132002     /lib/i386-linux-gnu/libm-2.15.so
b7721000-b7724000 rw-p 00000000 00:00 0
b7724000-b7725000 r-xp 00000000 00:00 0          [vdso]
b7725000-b7745000 r-xp 00000000 08:05 131950     /lib/i386-linux-gnu/ld-2.15.so
b7745000-b7746000 r--p 0001f000 08:05 131950     /lib/i386-linux-gnu/ld-2.15.so
b7746000-b7747000 rw-p 00020000 08:05 131950     /lib/i386-linux-gnu/ld-2.15.so
bfa8f000-bfab1000 rw-p 00000000 00:00 0          [stack]
Aborted (core dumped)
mamadou@mamadou-HP-Pavilion-dv6700-Notebook-PC:~/Documents$ ^C
mamadou@mamadou-HP-Pavilion-dv6700-Notebook-PC:~/Documents$

Thanks for help

Login to leave a comment.