f



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

Hello all,

I am using Intel Fortran Intel(R) 64 Compiler XE for applications running o=
n Intel(R) 64, Version 13.1.0.146 Build 20130121 on Fedora 18. I have a for=
tran program (*.f90) which is continuously giving the 'Segmentation fault e=
rror' when I am executing my fortran program after compiling with ifort.=20

I execute as below:
$ ifort -o myprogram myprogram.f90 # creates the object file
$ ./myprogram   # Segmentation fault error pops up on the screen

First, I would like to know what are the various reasons for 'Segmentation =
fault error'? Is it a bug with the compiler version?=20

While if I run the same program on gfortran ( gcc version 4.7.2 20121109 (R=
ed Hat 4.7.2-8) ), I got the following error message when I executed as bel=
ow:

$ gfortran -o myprogram myprogram.f90
$ ./myprogram

*** glibc detected *** ./vector3: munmap_chunk(): invalid pointer: 0x000000=
00015dac50 ***
=3D=3D=3D=3D=3D=3D=3D Backtrace: =3D=3D=3D=3D=3D=3D=3D=3D=3D
/lib64/libc.so.6[0x30aba7b776]
../vector3[0x404df3]
../vector3[0x420aaf]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x30aba21a05]
../vector3[0x401089]
....
....
....

Why is this error coming when compiling with GFORTRAN?

After looking through various online forums, I got some typical consistent =
compile commands as below:

In GFORTRAN

$ gfortran -msse2 -O3 -v myprogram.f90
$ ./a.out

No error as seen above is observed but the output written is unexpected / i=
nconsistent.

In IFORT

$ ifort -msse2-fp-model source -V myprogram.f90
$ ./a.out

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

I would like to clarify that myprogram.f90 is a single Fortran program file=
 which also includes some subroutines and functions called in between. I gu=
ess the segmentation fault error has nothing to do with the syntax or the p=
rogram. May be I am wrong! I am sure the error is resulting due to compiler=
 issues. When I approached an IT person, he says that the Segmentation faul=
t always points to a problem concerning RAM operations. Also, he points tha=
t the only difference between ifort and gfortran is the optimization for in=
tel cpu's done by the intel fortran compiler. I am using a lenovo laptop an=
d I am not aware whether it has intel cpu or something else. Now I am compl=
etely at cross-roads wasting my time on figuring out issues that were no wa=
y related to my program structure / syntax errors.=20

Can any one suggest me on this?

Thanks in advance,
Madhavan
0
Madhavan
7/4/2013 8:05:59 AM
comp.lang.fortran 11941 articles. 1 followers. Post Follow

13 Replies
3278 Views

Similar Articles

[PageSpeed] 34

On 07/04/2013 10:05 AM, Madhavan Bomidi wrote:
> Hello all,
>
> I am using Intel Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.1.0.146 Build 20130121 on Fedora 18. I have a fortran program (*.f90) which is continuously giving the 'Segmentation fault error' when I am executing my fortran program after compiling with ifort.
>
> I execute as below:
> $ ifort -o myprogram myprogram.f90 # creates the object file
> $ ./myprogram   # Segmentation fault error pops up on the screen
>
> First, I would like to know what are the various reasons for 'Segmentation fault error'? Is it a bug with the compiler version?

The most common cause of a segmentation fault is an error in the user's 
code.  For instance:
  - accessing arrays out of bounds
  - accessing unallocated allocatable objects
  - dereferencing undefined or disassociated pointers
etc.

If your program segfaults with two different compilers, it is most 
likely not a compiler bug (which in principle could also be the cause).

So I would suggest that you compile and run your program with all 
possible checks turned on (bounds checking, in particular).  If this 
doesn't give a hint, you may run your program through a debugger or 
simply isolate the bug via print statements.

-- Wolfgang



-- 
E-mail: firstnameinitial.lastname@domain.de
Domain: yahoo
0
Wolfgang
7/4/2013 8:20:36 AM
Madhavan Bomidi <blmadhavan@gmail.com> writes:

>First, I would like to know what are the various reasons for 'Segmentation =
>fault error'? Is it a bug with the compiler version?=20

Extremely unlikely compiler problem.
Extremely likely wrong logic in the program,
e.g. accessing elements beyond array bounds.
You need to debug your program.

>Why is this error coming when compiling with GFORTRAN?

not compiling, running. If you don't see the difference,
you need to do some reading on the basics of
compiling/linking/executing flow.

>$ gfortran -msse2 -O3 -v myprogram.f90

If you are getting segfaults, you should definitely
revert to default optimisation level.

>I would like to clarify that myprogram.f90 is a single Fortran program file=
> which also includes some subroutines and functions called in between. I gu=
>ess the segmentation fault error has nothing to do with the syntax or the p=
>rogram. May be I am wrong!

I think you are completely wrong.
You get segfaults with two very good compilers,
and you think your program is not to blame?

>d I am not aware whether it has intel cpu or something else. Now I am compl=
>etely at cross-roads wasting my time on figuring out issues that were no wa=
>y related to my program structure / syntax errors.=20

"no way related"?
You are kidding yourself.
Debug your program, nothing more to say.

Anton
0
Anton
7/4/2013 8:27:21 AM
Hello all,

I have a MAC OS X Version 10.8.2 and i used Xcode 4.5 and gfortran version =
4.8.0. My code could be compiled and run without any problem. But an update=
 in the Xcode changed the settings in the gfortran (I am not familiar with =
these things). Form that point and without changing anyhting I could not ru=
n my code and I had the following backtrace

$ gfortran -o myprogram myprogram.f90=20
$ ./myprogram=20

*** glibc detected *** ./vector3: munmap_chunk(): invalid pointer: 0x000000=
00015dac50 ***=20
=3D=3D=3D=3D=3D=3D=3D Backtrace: =3D=3D=3D=3D=3D=3D=3D=3D=3D=20
/lib64/libc.so.6[0x30aba7b776]=20
../vector3[0x404df3]=20
../vector3[0x420aaf]=20
/lib64/libc.so.6(__libc_start_main+0xf5)[0x30aba21a05]=20
../vector3[0x401089]=20
....=20
....=20
....=20

If there is no problem with a bug in the compiler or the missing libraries =
and so on, why my code run without problems.

Any suggestions?

Than you very much in advance.
Vasileios
0
mparlakasvas
7/4/2013 8:50:10 AM
Op donderdag 4 juli 2013 10:50:10 UTC+2 schreef mparla...@yahoo.gr het volg=
ende:
> Hello all,
>=20
> I have a MAC OS X Version 10.8.2 and i used Xcode 4.5 and gfortran versio=
n 4.8.0. My code could be compiled and run without any problem. But an upda=
te in the Xcode changed the settings in the gfortran (I am not familiar wit=
h these things). Form that point and without changing anyhting I could not =
run my code and I had the following backtrace
>=20
....
>=20
> If there is no problem with a bug in the compiler or the missing librarie=
s and so on, why my code run without problems.
>=20
> Any suggestions?
>
> Than you very much in advance.
>=20
> Vasileios

Earlier in this thread people have given several suggestions as to possible
causes. =20

If your program is crashing after an update of the compiler or supporting
software, then it is quite possible and very likely even that the bug is
now exposed, whereas before it did not have immediately visible effects.

One way to find out is to use the compiler options that will give you a=20
more detailed traceback. I think it is -fbacktrace in gfortran. That should
give you an idea of where it is happening in the source code.

Also, compiling with array bound checking and the like may help.

Regards,

Arjen
0
Arjen
7/4/2013 9:18:03 AM
Dear all,

I tried to install older versions from both Xcode and gfortran (but not what I had in the beginning - I could not find them). Then sth strange happened. Sometimes the code ran very fast (as before not even 1 second), but some other times it stuck....

I already tried the backtrace... but nothing different than the old message.

Thank you all,
Vasileios 
0
mparlakasvas
7/4/2013 10:56:11 AM
Op donderdag 4 juli 2013 12:56:11 UTC+2 schreef mparla...@yahoo.gr het volgende:
> Dear all,
> 
> I tried to install older versions from both Xcode and gfortran (but not what I had in the beginning - I could not find them). Then sth strange happened. Sometimes the code ran very fast (as before not even 1 second), but some other times it stuck....
> 
> I already tried the backtrace... but nothing different than the old message.
> 
> Thank you all,
> Vasileios

I suggest you add print statements to your program to determine what parts
are being run and where it stops. This could also help to determine where
the difference in computational speed is coming from. 

Just one wild guess:
It might be that you have an uninitialized variable somewhere - if that is
used as the upper bound of a do-loop, that could explain the erratic timings
you get. 

Have you used "IMPLICIT NONE" throughout your program? If not, a typo could
easily lead to the above situation.

Regards,

Arjen

0
Arjen
7/4/2013 12:47:30 PM
<mparlakasvas@yahoo.gr> wrote:

> If there is no problem with a bug in the compiler or the missing libraries
> and so on, why my code run without problems.

> Any suggestions?

The kinds of programming bugs that most often cause segmentation faults
are very prone to causing different symptoms depending on all kinds of
trivial changes. That's because the bugs involve accidentally accessing
wrong memory locations. The symptoms can vary depending on exactly what
wrong location is accesed, which in turn can vary depending on almost
anything. That includes sometimes showing no symptoms. The bugs still
exists, even when they show no symptoms.

In the first reply to your original post, Wolfgang listed some of the
most common causes of segmentation faults and some of the fruitful
general ways to help search for them. Not having the actual code or any
other concrete data, I can't add much more to that except for one
suggestion.

That suggestion is to completely forget about compiler bugs. Whereas
compiler bugs do exist, they are far more rare than bugs in user code.
Your symptoms do *NOT* sound like those of compiler bugs, but *DO* sound
very much like common bugs in user code. Thinking about compiler bugs is
ging to do nothing other than distract you from finding the bugs in the
code. I'd bet money on it - quite a lot of money. That's based on 45
years of tracing down lots of bugs in my own code, helping other people
find bugs in theirs, and yes, occasionally even finding compiler bugs.

-- 
Richard Maine
email: last name at domain . net
domain: summer-triangle
0
nospam
7/4/2013 3:38:16 PM
On Thu, 04 Jul 2013 01:50:10 -0700, mparlakasvas wrote:

> Hello all,
> 
> I have a MAC OS X Version 10.8.2 and i used Xcode 4.5 and gfortran version 4.8.0.

If you have gfortran, then try compiling the code with -fcheck=all.  This adds array
index checking and other useful, but otherwise, very slow consistency checking.

-- 
steve
0
Steven
7/4/2013 4:16:01 PM
Steven G. Kargl wrote:
> On Thu, 04 Jul 2013 01:50:10 -0700, mparlakasvas wrote:
>> I have a MAC OS X Version 10.8.2 and i used Xcode 4.5 and gfortran version 4.8.0.
>
> If you have gfortran, then try compiling the code with -fcheck=all.  This adds array
> index checking and other useful, but otherwise, very slow consistency checking.

And with ifort, use "-check all" (which has similar checks).

Additionally, you can try gfortran's -finit-*, which might help finding 
an uninitialized variable. Cf. 
http://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html

Tobias
0
Tobias
7/4/2013 5:26:02 PM
Richard Maine <nospam@see.signature> wrote:
> <mparlakasvas@yahoo.gr> wrote:
 
>> If there is no problem with a bug in the compiler or the 
>> missing libraries and so on, why my code run without problems.
 
>> Any suggestions?
 
> The kinds of programming bugs that most often cause segmentation faults
> are very prone to causing different symptoms depending on all kinds of
> trivial changes. That's because the bugs involve accidentally accessing
> wrong memory locations. The symptoms can vary depending on exactly what
> wrong location is accesed, which in turn can vary depending on almost
> anything. That includes sometimes showing no symptoms. The bugs still
> exists, even when they show no symptoms.

Even more, the locations being accessed can vary based on input data.
For programs using random numbers without a constant seed, they
can vary from one run to the next.

Many implementations of memory allocation store the data needed to
keep track of allocated memory right before that used by the user.
Accessing one or two elements before the beginning of an array
easily writes over that, causing problems like those shown. 
(Just past the end, plus any padding, is the data for the next
allocated block.) 

-- glen
0
glen
7/4/2013 6:11:15 PM
On Thursday, July 4, 2013 6:05:59 PM UTC+10, Madhavan Bomidi wrote:
> Hello all,
>=20
>=20
>=20
> I am using Intel Fortran Intel(R) 64 Compiler XE for applications running=
 on Intel(R) 64, Version 13.1.0.146 Build 20130121 on Fedora 18. I have a f=
ortran program (*.f90) which is continuously giving the 'Segmentation fault=
 error' when I am executing my fortran program after compiling with ifort.=
=20
>=20
>=20
>=20
> I execute as below:
>=20
> $ ifort -o myprogram myprogram.f90 # creates the object file
>=20
> $ ./myprogram   # Segmentation fault error pops up on the screen
>=20
>=20
>=20
> First, I would like to know what are the various reasons for 'Segmentatio=
n fault error'? Is it a bug with the compiler version?=20
>=20
>=20
>=20
> While if I run the same program on gfortran ( gcc version 4.7.2 20121109 =
(Red Hat 4.7.2-8) ), I got the following error message when I executed as b=
elow:
>=20
>=20
>=20
> $ gfortran -o myprogram myprogram.f90
>=20
> $ ./myprogram
>=20
>=20
>=20
> *** glibc detected *** ./vector3: munmap_chunk(): invalid pointer: 0x0000=
0000015dac50 ***
>=20
> =3D=3D=3D=3D=3D=3D=3D Backtrace: =3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> /lib64/libc.so.6[0x30aba7b776]
>=20
> ./vector3[0x404df3]
>=20
> ./vector3[0x420aaf]
>=20
> /lib64/libc.so.6(__libc_start_main+0xf5)[0x30aba21a05]
>=20
> ./vector3[0x401089]
>=20
> ...
>=20
> ...
>=20
> ...
>=20
>=20
>=20
> Why is this error coming when compiling with GFORTRAN?
>=20
>=20
>=20
> After looking through various online forums, I got some typical consisten=
t compile commands as below:
>=20
>=20
>=20
> In GFORTRAN
>=20
>=20
>=20
> $ gfortran -msse2 -O3 -v myprogram.f90
>=20
> $ ./a.out
>=20
>=20
>=20
> No error as seen above is observed but the output written is unexpected /=
 inconsistent.
>=20
>=20
>=20
> In IFORT
>=20
>=20
>=20
> $ ifort -msse2-fp-model source -V myprogram.f90
>=20
> $ ./a.out
>=20
>=20
>=20
> forrtl: severe (174): SIGSEGV, segmentation fault occurred
>=20
> ...
>=20
> ...
>=20
> ...
>=20
> ...
>=20
>=20
>=20
> I would like to clarify that myprogram.f90 is a single Fortran program fi=
le which also includes some subroutines and functions called in between. I =
guess the segmentation fault error has nothing to do with the syntax or the=
 program. May be I am wrong! I am sure the error is resulting due to compil=
er issues. When I approached an IT person, he says that the Segmentation fa=
ult always points to a problem concerning RAM operations. Also, he points t=
hat the only difference between ifort and gfortran is the optimization for =
intel cpu's done by the intel fortran compiler. I am using a lenovo laptop =
and I am not aware whether it has intel cpu or something else. Now I am com=
pletely at cross-roads wasting my time on figuring out issues that were no =
way related to my program structure / syntax errors.=20
>=20
>=20
>=20
> Can any one suggest me on this?

Segment faults are usually caused by programming errors --
in particular, subscript errors.
You need to turn on all checks (including, of course, subscript
checks).

0
robin
7/4/2013 8:58:56 PM
Intel have produced a useful guide on this very topic

http://software.intel.com/en-us/articles/determining-root-cause-of-sigsegv-=
or-sigbus-errors

It's worth reading even if you are not using Intel's compilers.

Mark

On Thursday, 4 July 2013 09:05:59 UTC+1, Madhavan Bomidi  wrote:
> Hello all,
>=20
>=20
>=20
> I am using Intel Fortran Intel(R) 64 Compiler XE for applications running=
 on Intel(R) 64, Version 13.1.0.146 Build 20130121 on Fedora 18. I have a f=
ortran program (*.f90) which is continuously giving the 'Segmentation fault=
 error' when I am executing my fortran program after compiling with ifort.=
=20
>=20
>=20
>=20
> I execute as below:
>=20
> $ ifort -o myprogram myprogram.f90 # creates the object file
>=20
> $ ./myprogram   # Segmentation fault error pops up on the screen
>=20
>=20
>=20
> First, I would like to know what are the various reasons for 'Segmentatio=
n fault error'? Is it a bug with the compiler version?=20
>=20
>=20
>=20
> While if I run the same program on gfortran ( gcc version 4.7.2 20121109 =
(Red Hat 4.7.2-8) ), I got the following error message when I executed as b=
elow:
>=20
>=20
>=20
> $ gfortran -o myprogram myprogram.f90
>=20
> $ ./myprogram
>=20
>=20
>=20
> *** glibc detected *** ./vector3: munmap_chunk(): invalid pointer: 0x0000=
0000015dac50 ***
>=20
> =3D=3D=3D=3D=3D=3D=3D Backtrace: =3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> /lib64/libc.so.6[0x30aba7b776]
>=20
> ./vector3[0x404df3]
>=20
> ./vector3[0x420aaf]
>=20
> /lib64/libc.so.6(__libc_start_main+0xf5)[0x30aba21a05]
>=20
> ./vector3[0x401089]
>=20
> ...
>=20
> ...
>=20
> ...
>=20
>=20
>=20
> Why is this error coming when compiling with GFORTRAN?
>=20
>=20
>=20
> After looking through various online forums, I got some typical consisten=
t compile commands as below:
>=20
>=20
>=20
> In GFORTRAN
>=20
>=20
>=20
> $ gfortran -msse2 -O3 -v myprogram.f90
>=20
> $ ./a.out
>=20
>=20
>=20
> No error as seen above is observed but the output written is unexpected /=
 inconsistent.
>=20
>=20
>=20
> In IFORT
>=20
>=20
>=20
> $ ifort -msse2-fp-model source -V myprogram.f90
>=20
> $ ./a.out
>=20
>=20
>=20
> forrtl: severe (174): SIGSEGV, segmentation fault occurred
>=20
> ...
>=20
> ...
>=20
> ...
>=20
> ...
>=20
>=20
>=20
> I would like to clarify that myprogram.f90 is a single Fortran program fi=
le which also includes some subroutines and functions called in between. I =
guess the segmentation fault error has nothing to do with the syntax or the=
 program. May be I am wrong! I am sure the error is resulting due to compil=
er issues. When I approached an IT person, he says that the Segmentation fa=
ult always points to a problem concerning RAM operations. Also, he points t=
hat the only difference between ifort and gfortran is the optimization for =
intel cpu's done by the intel fortran compiler. I am using a lenovo laptop =
and I am not aware whether it has intel cpu or something else. Now I am com=
pletely at cross-roads wasting my time on figuring out issues that were no =
way related to my program structure / syntax errors.=20
>=20
>=20
>=20
> Can any one suggest me on this?
>=20
>=20
>=20
> Thanks in advance,
>=20
> Madhavan
0
Mark
7/5/2013 9:36:13 AM
On 7/4/13 10:38 AM, Richard Maine wrote:
> <mparlakasvas@yahoo.gr>  wrote:
>
>> If there is no problem with a bug in the compiler or the missing libraries
>> and so on, why my code run without problems.
>
>> Any suggestions?
>
> The kinds of programming bugs that most often cause segmentation faults
> are very prone to causing different symptoms depending on all kinds of
> trivial changes. That's because the bugs involve accidentally accessing
> wrong memory locations. The symptoms can vary depending on exactly what
> wrong location is accesed, which in turn can vary depending on almost
> anything. That includes sometimes showing no symptoms. The bugs still
> exists, even when they show no symptoms.
>
> In the first reply to your original post, Wolfgang listed some of the
> most common causes of segmentation faults and some of the fruitful
> general ways to help search for them. Not having the actual code or any
> other concrete data, I can't add much more to that except for one
> suggestion.
>
> That suggestion is to completely forget about compiler bugs. Whereas
> compiler bugs do exist, they are far more rare than bugs in user code.
> Your symptoms do *NOT* sound like those of compiler bugs, but *DO* sound
> very much like common bugs in user code. Thinking about compiler bugs is
> ging to do nothing other than distract you from finding the bugs in the
> code. I'd bet money on it - quite a lot of money. That's based on 45
> years of tracing down lots of bugs in my own code, helping other people
> find bugs in theirs, and yes, occasionally even finding compiler bugs.
>
There's one other possibility that I don't think has been mentioned. 
Put all of your subroutines and functions in a MODULE and USE the 
module.  Many of the "new" Fortran 90 features require an explicit 
interface and that's best provided by a MODULE/USE pair.  (This is 
especially true with array arguments where a lot of information is 
passed by magic by the compiler.)  Different compilers pass arguments in 
different ways and simple cases can "work" sometimes even though they 
are incorrect Fortran.

Dick Hendrickson
0
Dick
7/5/2013 3:44:47 PM
Reply: