- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
How could one help you if you do not show any sources? Please provide a small reproducer that shows the segmentation violation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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#comment-1548435 . 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 >
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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".
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page