Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
92 Views

SIGSEGV, segmentation fault

Sir

 

I am running my source codes on Linux 14.04/ 16.04 using Inter ifort version 18.0.1. I am getting error as mentioned below.

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
xs            0000000000418BAD  Unknown               Unknown  Unknown
libpthread-2.19.s  00007F2FB0881330  Unknown               Unknown  Unknown
xs            00000000004D4FA9  Unknown               Unknown  Unknown
xs              0000000000435774  Unknown               Unknown  Unknown
xs              00000000004037B7  orddrv_                   221  xs.f
xs             00000000004032D8  MAIN__                     66  xs.f
xs            000000000040325E  Unknown               Unknown  Unknown
libc.so.6          00007F2FB04CAF45  __libc_start_main     Unknown  Unknown
xs              0000000000403169  Unknown

i used version ifort version 17 earlier. Using it, I compiled binaries. I am still able to run the codes successfully.

pl help me to overcome the problem and resolve the issue

0 Kudos
16 Replies
Highlighted
Valued Contributor I
92 Views

How could one help you if you do not show any sources? Please provide a small reproducer that shows the segmentation violation. 

0 Kudos
Highlighted
Black Belt
92 Views

You will need to provide all the source files needed to build and run the program, plus any input data needed. State the compiler options that you used.

0 Kudos
Highlighted
Beginner
92 Views

Pl find files attached in folders.

 

The folder 1 UKRMoL contains folders source codes, bib, lib and make files

you may try to create executables. You need to mention paths correctly by simply mentioning in make.inc.ou file

the 2nd folder contains bin and input folder. the bin contains all necessary binaries. you type ./jobfile the coutputs will be created and at the end you will see  this message.. this refers to second file  pl note 2nd will run once 1st file has successfully run

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

Image              PC                Routine            Line        Source             
sword              0000000000418BAD  Unknown               Unknown  Unknown
libpthread-2.19.s  00007F2595D68330  Unknown               Unknown  Unknown
sword              00000000004D4FA9  Unknown               Unknown  Unknown
sword              0000000000435774  Unknown               Unknown  Unknown
sword              00000000004037B7  orddrv_                   221  sword.f
sword              00000000004032D8  MAIN__                     66  sword.f
sword              000000000040325E  Unknown               Unknown  Unknown
libc.so.6          00007F25959B1F45  __libc_start_main     Unknown  Unknown
sword              0000000000403169  Unknown               Unknown  Unknown

 

I am running my source codes on Linux 14.04/ 16.04 using Inter ifort version 18.0.1. I am getting error as mentioned below.

hope i have clarified and provided all inputs

thanks for efforts

 

ab

0 Kudos
Highlighted
Black Belt
92 Views

My, that is a large package with many pieces that depend on MKL, Arpack, etc. I did not want to build the whole thing, so I looked at your makefile and, from that, this is what I gathered: (i) Program swmol3 reads the input data in file int.inp (produced from the "heredoc" in the se-1.0 script) and produces an unformatted file, fort.2; (ii) Program sword reads the input data in file ord.inp (generated from another "heredoc" in the se-1.0 script) and the file fort.2 from the first step.

I built swmol3 and sword using Ifort 18.0.1, with the options -traceback -C. The swmol3 program uses a couple of BLAS and Lapack routines, which I got from MKL. Note that I did not use any parallel options nor -i8. Line 995 of sword.f contains a bug, since it compares a logical variable to the integer 0, so I replaced the condition by .NOT.zdelta; please check/verify what was intended here.

I ran swmol3 and then sword. Both ran fine and produced seemingly correct output (I know nothing of your application). I suspect from the line numbers in your traceback that sword did not find the file fort.2 in the current directory, as it expected. You would be wise to add a STATUS='OLD' clause to the file OPEN statement. Otherwise, a zero length file is created, and when a READ is attempted failure would occur.

The last segment of the output of sword was:

          ***** Formatting of header records completed 


 One-electron integral ordering completed 
 In core sort of case  I I I I         20971
 ***** reading file: case, unit           2           1

 Memory required is          0 Mbytes
 Two-electron ordering for  I I I I completed 

 In core sort of case  I J I J         34360
 ***** reading file: case, unit          81           2

 Memory required is          0 Mbytes
 Two-electron ordering for  I J I J completed 

 In core sort of case  I I J J         10527
 ***** reading file: case, unit          82           3

 Memory required is          0 Mbytes
 Two-electron ordering for  I I J J completed 

 In core sort of case  I J K L          5184
 ***** reading file: case, unit          83           4

 Memory required is          0 Mbytes
 Two-electron ordering for  I J K L completed 

 

0 Kudos
Highlighted
Beginner
92 Views

Sincere Thanks Mr mecej4

These codes are written by various researchers. I simply use them . hence my understanding is limited. though i knew where/ which part is causing this. thanks for a detailed explanation.

let me try to understand correctly   you say error in 995 of sword. file

     IF (zdelta.eq.0) THEN   should be replaced as      IF (zdelta.NOT.0) THEN             am i correct

2 You would be wise to add a STATUS='OLD' clause to the file OPEN statement..........

where / whch part/ file should i add  STATUS='OLD'

3 how to use traceback option.... you built  swmol3 and sword using Ifort 18.0.1, with the options -traceback -C.  pl explain me how to use this

4  previously i used same codes on linus 14.04 and could successfully compiled codes. i infact excuted several examples but didi not face any issue. then my ifort was 17..... is this problem attributed to new compiler ?

5   pl share swmpol3 and sword.f files that you used to run the code

sincerly yours

0 Kudos
Highlighted
Black Belt
92 Views

If you are simply a user of the code, it would be best for you to tell the authors/maintainers of the package about line 995 of SWORD.F. Details of the issue are covered at https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/275071#comme... . In the case you are running, ZDELTA is set to .FALSE. and the bug will not be active since that line is never reached. There is no need for me to give you any files, since all the files are contained in the attachment that you posted.

You have already built the two executables. Simply change to the directory where you have the script se-1.0. Check that the script has the correct paths to the executables, and run it. If that does not work,  create the files int.inp and ord.inp from the contents of the script. The command swmol3 < int.inp should produce five files fort.2, fort.13, fort.81, fort.82 and fort.83. then, the command sword < ord.inp should run to completion and produce two more files, fort.18 and fort.144.

If you are not comfortable with the instructions in the preceding paragraph, you should probably take some short course on basic running of programs on Linux or read some online tutorials.

0 Kudos
Highlighted
Beginner
92 Views

sir then why could i run the files successfully using same code. I got correct results. the difference from this time and earlier is now i am using ifort 18.0.1 and then 17.1

is issue related to compiler versions >

0 Kudos
Highlighted
Black Belt
92 Views

I ran your case with the 18.0.1 compiler on Linux, and with the CVF 6.6C compiler on Windows. In neither case did I see a crash. You are jumping to the conclusion that the compiler version is solely responsible for the crash. There is no proof of that, and there can be a number of other reasons.  For one, the programs require large stacks. If your stack allocation is inadequate, a crash could occur.

I suggest that you run each step separately, instead of running the script. The script assumes that each step will complete and output valid files. If a step fails, and the output is redirected, you will not see any sign of things having gone wrong, until much later.

0 Kudos
Highlighted
Beginner
92 Views

is there any way i get license or serial no for intel compiler 2016.1.150  or 2017.1.132

since i used them earlier and cud successfully create binaries. i have just tested in my original form, the codes are running without any issue

when i set

ZDELTA = .true.

ab

0 Kudos
Highlighted
Black Belt
92 Views

If you have registered your serial number at https://registrationcenter.intel.com/en/products/, you can log in there and choose one of the older versions of the compiler packages there. Your current license will also work for the older product.

I can almost guarantee that installing the older compiler will be a waste of time. The error in #4 has nothing to do with the compiler. The traceback is from the second program, which the compiler built successfully. Line 221 of sword.f is where the crash occurred. The statement in question is

     READ(ITAPE,ERR=201)CLABEL, NSYMT, (NBFT(I),I=1,NSYMT), POTNUC, 
     &                   IDOSPH

You can confirm this for yourself. Compile and link the first two programs without using any of the complex options, OpenMP, MPI, etc., but do specify -traceback. List the fort.nn files after you have run swmol3 < int.inp. You should see something similar to:

 12012 Mar 25 07:22 fort.13
203136 Mar 25 07:22 fort.2
259564 Mar 25 07:22 fort.81
163444 Mar 25 07:22 fort.82
 86548 Mar 25 07:22 fort.83

Now run sword < ord.inp. There will be no crash, just normal output. Now, delete the fort.2 file and run sword again, as before. Now, the program will crash and give the traceback that you reported in #4. 

The suggested fix was to add status='old' to the OPEN statement on Line 202 of sword.f.

0 Kudos
Highlighted
Beginner
92 Views

is this correct way of setting the environment using ubuntu 16.04 64 bits platform for intel fortran compiler. the line is mentioned in bash file

source /opt/intel/parallel_studio_xe_2018.1.038/bin/psxevars.sh

2  am i supposed to do something extra so that intel libraries are shared correctly

3 how do i ensure all threads/lib files are linked or shared correctly

thanks

0 Kudos
Highlighted
Black Belt
92 Views

There are similar shell scripts, ifortvars.sh and compilervars.sh, with similar purposes, depending on which version of Parallel Studio/Composer was installed. They all require one argument, which names the target architecture: "ia32" or "intel64".

After you have run the script, in that shell session your a.outs can use the Intel shared libraries. If you now move to another shell window, however, the Intel shared libraries (such as MKL *.so) will not be accessible unless you set LD_LIBRARY_PATH, PATH, etc.

0 Kudos
Highlighted
Beginner
92 Views

to ensure i use the Intel shared libraries (such as MKL *.so) when i open new window, the LD_LIBRARY_PATH, PATH, etc. be mentioned in bash file itself ?

export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH

2 when i open a new window i get on top the message     "Intel(R) Parallel Studio XE 2018 Update 1 for Linux* Copyright (C) 2009-2017 Intel Corporation. All rights reserved."

this i never got before. thus i am apprehensive if ifort is correctly installed

 

ab

 

0 Kudos
Highlighted
Black Belt
92 Views

Given the large number of slightly different distributions of Linux, see https://linuxhere.wordpress.com/history-of-linux-distributions-distro/, ;I cannot answer any questions that are specific to your version. However, everything looks fine. You should not have to modify LD_LIBRARY_PATH -- the ifortvars.sh script would have done that -- and Ifort is probably not installed in the /usr/local branch but somewhere under /opt. The details do not matter unless you start modifying the installation, which you have no reason to do now. 

For your initial work, I suggest that you copy the necessary source files and input files to a new working directory and build there. You do not need makefiles, Arpack, etc. Keep things simple until you get it to work.

0 Kudos
Highlighted
Beginner
92 Views

Strange !

i managed parallel studio 2017 (evaluative version). i compiled binaries and tried running codes. It worked !! there was no segmentation fault. i didnt change the sword.f file. as suggested i worked with modifications in sword file. it too worked.

i then tried using 2018 ifort version. It worked too. i got desired output with original and modified codes.

i only made one change.  i mentioned in bash file /opt/intel/2017/bin/ifortvars.sh intel64   2017 as i installed in it. 

while running 2018 version i retained the same path. and didnot set environment for this version

it seems it was a linking error. Pl explain as will be of help in future as well

  • ab
0 Kudos
Highlighted
Black Belt
92 Views

You may have any number of different versions of Parallel Studio installed, but the compiler version that will be used when invoked as "ifort"is the first one in the current path. Thus, if you sourced the ifortvars.sh from PS2017, you would have used only the 2017 compiler.

I have no idea what you mean by "it was a linking error", nor have you shown the basis for reaching that conclusion. Therefore, unless you document what you found more thoroughly, I am afraid that there is hardly anything to "explain".

0 Kudos