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

[jpprieto]

Hi, I continue with both my work and my problems.
The situation: I'm running two codes in diferent lenguages, one is in f90 and the otherone in c. To do the fusion between these programs I creat all .o to link it. The .f90 program calls a function in the .c program. The link is Ok.
The problem: When I open a file from .c program the aplication is stopped with the following message:
forrtl: severe (174): SIGSEGV, segmentation fault occurred
This is the line of the error:

double IR13RM(double AEXP)
{
FILE *archsigmaLi;
double dfrec,dA,A,frecLi1,sigmaLi1,frecLi2,sigmaLi2;

archsigmaLi=fopen("sigmaLi.dat","r");
A=0.0;
fscanf(archsigmaLi,"%lf %lf\n",&frecLi1,&sigmaLi1);

At the moment of scanf the program is stopped.
Some idea about what is wrong here?
An interesting thing is that when I run the .c program alone, the file is read in a good way and all is Ok.
Thank you.

[rreis]

Quoting - jpprieto

Hi, this is my first time in this forum.
I'm working with a .f program which is compiled with gcc. This program takes integer and real variables and write it in a file. This file is read in a .f90 (here the variables are integer and real(sp) ) program compiled with ifort, but here the numbers are defferent from the written with the .f program.
Can someone help me?
Cheers.

- you mean... g77 or gfortran?
- is it the .f and the .f90 the same program?
- are they using the same precision?

[TimP]

Your questions are likely to be covered in previous discussions on this forum, or possibly on the Windows forum. To avoid guesses, you would have to be more specific about the compiler and operating system versions involved, and the compile commands. Most likely, you haven't used consistent options between gfortran (or g77?) and ifort, or you made a mistake in your .f vs .f90 usage. All of these compilers default to f77 standard "fixed format" source when the file name is .f. Both ifort and gfortran default to free form for files named .f90. To see the versions, include the -v option in your gfortran or g77 command line, and -V in your ifort command line.
Typical consistent compile commands might be
gfortran -msse2 -O3 -v yourprogram.f
In order to cover ifort versions 9.1 through 11:
ifort -xW -fp-model precise -V yourprogram.f

gfortran didn't become reliable until about version 4.2.1. To a limited extent, using gcc to compile a .f file would select g77 or gfortran automatically.

[jpprieto]

Quoting - tim18

Your questions are likely to be covered in previous discussions on this forum, or possibly on the Windows forum. To avoid guesses, you would have to be more specific about the compiler and operating system versions involved, and the compile commands. Most likely, you haven't used consistent options between gfortran (or g77?) and ifort, or you made a mistake in your .f vs .f90 usage. All of these compilers default to f77 standard "fixed format" source when the file name is .f. Both ifort and gfortran default to free form for files named .f90. To see the versions, include the -v option in your gfortran or g77 command line, and -V in your ifort command line.
Typical consistent compile commands might be
gfortran -msse2 -O3 -v yourprogram.f
In order to cover ifort versions 9.1 through 11:
ifort -xW -fp-model precise -V yourprogram.f

gfortran didn't become reliable until about version 4.2.1. To a limited extent, using gcc to compile a .f file would select g77 or gfortran automatically.

Hi. The codes, .f and .f90 are different.
I'm compiling .f file with g77
g77 -v
gcc version 3.4.6 20060404 (Red Hat 3.4.6-4)
and the .f90 file with
ifort -v
Version 10.0
This is the problem. file.f takes 3 parameters from a .inc:
...
integer np1,np2,np3
parameter (np1=128,np2=128,np3=128)
...
Afterward file.f writes these parameters in different file:
...
open(11,file='ic_velcz',form='unformatted')
end if
rewind 11
write(11) np1,np2,np3,dx,x1o+xoff,x2o+xoff,x3o+xoff,
& astart,omegam,omegav,h0
...
Afterward, file.90 should read this file to get these three parameters (n1, n2 and n3) to be used. The file.f90:
...
integer ,dimension(1:MAXLEVEL)::n1,n2,n3
...
open(10,file=filename,form='unformatted')
if(myid==1)write(*,*)'Reading file '//TRIM(filename)
rewind 10
read(10) n1(ilevel),n2(ilevel),n3(ilevel),dxini0 &
& ,xoff10,xoff20,xoff30 &
& ,astart0,omega_m0,omega_l0,h00
close(10)
...
Here is the problem. file.f90 finds:

coarser grid is not compatible with initial conditions file
Found n1= 0 n2= 128 n3= 128
Expected n1= 128 n2= 128 n3= 128

Why n1 is different from np1? These number are 32-bit integers. some idea about wath is going on?
Thank you and cheers.

[jimdempseyatthecove]

Please supply 1st line of data file in your next post.

It looks as if np1 is being read as 0

Try some test code where you define parameter np1Test=111, np2Test=222,np3Test=333 and

write(11) np1Test,np2Test,np3Test,dx,x1o+xoff,x2o+xoff,x3o+xoff,
& astart,omegam,omegav,h0

Then run to produce file (with incorrect values)
Then place break after

read(10) n1(ilevel),n2(ilevel),n3(ilevel),dxini0 &
& ,xoff10,xoff20,xoff30 &
& ,astart0,omega_m0,omega_l0,h00

and see what is read.

Jim

[jpprieto]

Quoting - jimdempseyatthecove

Please supply 1st line of data file in your next post.

It looks as if np1 is being read as 0

Try some test code where you define parameter np1Test=111, np2Test=222,np3Test=333 and

write(11) np1Test,np2Test,np3Test,dx,x1o+xoff,x2o+xoff,x3o+xoff,
& astart,omegam,omegav,h0

Then run to produce file (with incorrect values)
Then place break after

read(10) n1(ilevel),n2(ilevel),n3(ilevel),dxini0 &
& ,xoff10,xoff20,xoff30 &
& ,astart0,omega_m0,omega_l0,h00

and see what is read.

Jim

Hi, I saw what happened:
The problem is the same, file.f90 reads 0 in place of 128 and the following real numbers are completely differents.
I think could be a big-little endian problem...
Some idea?

[Kevin_D_Intel]

Based on my testing, it appears you are on a 64-bit system (e.g. Intel 64 or compatible). Following Jim's advice, the output would render: 0 111 222

On a 32-bit system, the unformatted file is compatible between g77/ifort, but on the 64-bit system they are not and the record structure relates to this earlier post from Steve here.

[Kevin_D_Intel]

There may be a method to overcome this by reading the g77 produced file using stream I/O with ifort and writing it out in the compatible format for the second program that is built using ifort. I will do some testing on this.

Or alternatively, if possible, can you just compile both programs using ifort?

[Kevin_D_Intel]

Given Steve's description about the g77 unformatted record structure on the 64-bit platform, you can create a program that opens the original and a new file using access='STREAM'. Next, read from the original file, the first 64-bit length header as two 32-bit chunks, the record data (all your variables), and then the 64-bit length trailer as two 32-bit chunks. Then, write to the new file, the first 32-bit chunk of the header, the record data (all your variables), and the first 32-bit chunk of the trailer.

The program would like something like what is shown below. The program below only reads/writes a single unformatted record. If file.f writes other data to the ic_velcz, then you must construct similar read/write statements specific to that data. Since you did not show them earlier, you will need to add the proper type declarations as noted in the program for variables: dxini0,xoff10,xoff20,xoff30,astart0,omega_m0,omega_l0,h00

Once you have unfmt_convert.f90 ready, compile your file.f with g77 and then execute it to create the file ic_velcz. Next, using ifort, compile and run the unfmt_convert.f90 program as follows:

ifort unfmt_convert.f90 -o unfmt_convert
./unfmt_convert

After execution, you should be able to use the file ic_velcz_new as the input file to your file.f90 program that is compiled with ifort without making any source changes.

[plain]unfmt_convert.f90:

program unfmt_convert

 dxini0,xoff10,xoff20,xoff30,astart0,omega_m0,omega_l0,h00

integer np1, np2, np3
integer hdr1, hdr2, trl1, trl2

open(11,file='ic_velcz',access='stream',form='unformatted')
open(12,file='ic_velcz_new',access='stream',form='unformatted')

! From the original file, read 64-bit length header as two 
! 32-bit chunks, the record data (all your variables), 
! and then the 64-bit length trailer as two 32-bit chunks

read(11) hdr1,hdr2,np1,np2,np3,dxini0,xoff10,xoff20,xoff30, &
&           astart0,omega_m0,omega_l0,h00,trl1,trl2


! To the new file, write the first 32-bit chunk of the header, 
! the record data (all your variables), 
! and the first 32-bit chunk of the trailer.

write(12) hdr1,np1,np2,np3,dxini0,xoff10,xoff20,xoff30, &
&            astart0,omega_m0,omega_l0,h00,trl1

close (11)
close (12)
end[/plain]

[jpprieto]

Quoting - Kevin Davis (Intel)

Given Steve's description about the g77 unformatted record structure on the 64-bit platform, you can create a program that opens the original and a new file using access='STREAM'. Next, read from the original file, the first 64-bit length header as two 32-bit chunks, the record data (all your variables), and then the 64-bit length trailer as two 32-bit chunks. Then, write to the new file, the first 32-bit chunk of the header, the record data (all your variables), and the first 32-bit chunk of the trailer.

The program would like something like what is shown below. The program below only reads/writes a single unformatted record. If file.f writes other data to the ic_velcz, then you must construct similar read/write statements specific to that data. Since you did not show them earlier, you will need to add the proper type declarations as noted in the program for variables: dxini0,xoff10,xoff20,xoff30,astart0,omega_m0,omega_l0,h00

Once you have unfmt_convert.f90 ready, compile your file.f with g77 and then execute it to create the file ic_velcz. Next, using ifort, compile and run the unfmt_convert.f90 program as follows:

ifort unfmt_convert.f90 -o unfmt_convert
./unfmt_convert

After execution, you should be able to use the file ic_velcz_new as the input file to your file.f90 program that is compiled with ifort without making any source changes.

[plain]unfmt_convert.f90:

program unfmt_convert

 dxini0,xoff10,xoff20,xoff30,astart0,omega_m0,omega_l0,h00

integer np1, np2, np3
integer hdr1, hdr2, trl1, trl2

open(11,file='ic_velcz',access='stream',form='unformatted')
open(12,file='ic_velcz_new',access='stream',form='unformatted')

! From the original file, read 64-bit length header as two 
! 32-bit chunks, the record data (all your variables), 
! and then the 64-bit length trailer as two 32-bit chunks

read(11) hdr1,hdr2,np1,np2,np3,dxini0,xoff10,xoff20,xoff30, &
&           astart0,omega_m0,omega_l0,h00,trl1,trl2


! To the new file, write the first 32-bit chunk of the header
! the record data (all your variables), 
! and the first 32-bit chunk of the trailer.

write(12) hdr1,np1,np2,np3,dxini0,xoff10,xoff20,xoff30, &
&            astart0,omega_m0,omega_l0,h00,trl1

close (11)
close (12)
end[/plain]

Thank you, I compiled .f and .f90 files with ifort. The first time the compilation gave me a problem but the second time the compilation was good and the file was read in a good way.
thank you, very much.