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

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

moghaddam
Beginner
‎01-24-2008 02:03 PM
42,678 Views

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

0 Kudos

Link Copied

28 Replies
TimP
Honored Contributor III
‎04-28-2012 07:05 AM
2,388 Views
In past versions, the name of the compiler was fc or fce, both replaced quite a while ago by ifort.
0 Kudos
Copy link
TimP
Honored Contributor III
‎04-28-2012 07:11 AM
2,388 Views
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.
0 Kudos
Copy link
Steven_L_Intel1
Employee
‎04-28-2012 05:44 PM
2,388 Views
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?
0 Kudos
Copy link
alex0516
Beginner
‎05-07-2012 08:36 PM
2,388 Views
Quoting Alex Adams
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

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

0 Kudos
Copy link
TimP
Honored Contributor III
‎05-08-2012 03:27 AM
2,388 Views
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.
0 Kudos
Copy link
alex0516
Beginner
‎05-12-2012 06:56 AM
2,388 Views
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?

0 Kudos
Copy link
jimdempseyatthecove
Honored Contributor III
‎05-12-2012 07:58 AM
2,388 Views
>>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
0 Kudos
Copy link
Mamadou_Saliou_D_
Beginner
‎05-08-2014 05:57 AM
2,388 Views

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

0 Kudos
Copy link
Reply

Community support is provided Monday to Friday. Other contact methods are available here.

Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.

For more complete information about compiler optimizations, see our Optimization Notice.