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

environment and stack size

durgapal__shubham
710 Views

hello

i ma an undergrad student learning computational skils. recently, i compiled a binary using intel (R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 18.0.2.199 Build 20180210 running on ubuntu 14.04 64 bits OS.

test             0000000000418BBD  Unknown               Unknown  Unknown
libpthread-2.19.s  00002ADBE4BDD330  Unknown               Unknown  Unknown
test             00000000004D5356  Unknown               Unknown  Unknown
test            000000000043580F  Unknown               Unknown  Unknown
test              00000000004037BC  orddrv_                   221  test.f
test             00000000004032D8  MAIN__                     66  test.f
test              000000000040325E  Unknown               Unknown  Unknown
libc-2.19.so       00002ADBE4E0CF45  __libc_start_main     Unknown  Unknown
test             0000000000403169  Unknown               Unknown  Unknown

i understand its related to stack size in prog test. but what does the higlighted lines mean. besides am i missing some files required during run time ?

i have given  2 commands to increase stack size in bashrc file but i found no difference.

ulimit -s unlimited
export OMP_STACKSIZE=500M

i have also given following commands in .bashrc file to set environment
export PATH=$PATH:/opt/intel/bin
export PATH=$PATH:/usr/bin:/usr/local/bin

source /opt/intel/bin/compilervars.sh intel64
#source /opt/intel/bin/compilervars.sh ia32
export LD_LIBRARY_PATH=/usr/lib/:$LD_LIBRARY_PATH
export LIBRARY_PATH=/usr/lib:$LIBRARY_PATH

export LD_LIBRARY_PATH=/opt/intel/lib:$LD_LIBRARY_PATH

export LIBRARY_PATH=/opt/intel/mkl/lib/intel64:$LIBRARY_PATH

export MANPATH="/opt/intel/man"

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

what should i do ? kindly assists

shubham


export LD_LIBRARY_PATH=/opt/intel/mkl/lib/intel64:$LD_LIBRARY_PATH

0 Kudos
9 Replies
Juergen_R_R
Valued Contributor I
710 Views

This is a backtrace from a failing program 'test' that uses the external libraries libpthread and libc from the OS.

0 Kudos
durgapal__shubham
710 Views

thanks Mr Juergen.

You mean the prog is not able to find these two necessary files, and is causing error ?

how can it be resolved. i have tried increasing stacksize using ulimi -s unlimitedt command

what should i do more

shubham

0 Kudos
Juergen_R_R
Valued Contributor I
710 Views

No, the libraries are found. Without showing any of your code, there is nothing to be helped. 

0 Kudos
jimdempseyatthecove
Honored Contributor III
710 Views

The unknown(s) mean the line numbers within the file are unknown (due to the file in the library being compiled without traceback information - and/or - with debug information stripped). Displaying a line number within a 3rd party library is usually meaningless to an end-user.

I suggest looking at/near test.t ling 221

The report you provided did not include the error message. Could you please provide this.

Note, use the {...} code button and select Plain Text as the format.

Jim Dempsey

0 Kudos
durgapal__shubham
710 Views
0 Kudos
mecej4
Honored Contributor III
710 Views

I think that you will end up chasing a ghost by building a parallel version before you have make the program functional and without an awareness of the files that the program expects to be available.

Apparently, you have built the program sword. In order to run, this program needs to read several input files, one of which is expected to be read as standard input, and the rest are Fortran unformatted files. Typically, these unformatted files are produced by running another program such as swmol3 of the UKRMOL package. Do you have several files named fort.nn, where 'nn' stands for a number?

If these necessary files are not present in the working directory, the program will not run as expected. Worse, if the program attempts to open a file that should have been present but is not, without a STATUS clause in the OPEN statement, a zero-length file will be created. A subsequent READ from this file will fail, naturally. My guess is that these events were exactly what took place as a result of the statement in Line 221. If so, it will be futile to attempt to rectify the situation by changing environment variables, makefiles or compiler options. None of these can compensate for the missing data files!

Questions regarding the UKRMOL programs are not likely to be appropriate in this forum. There are several sites that you could approach with such questions: https://ccpforge.cse.rl.ac.uk/gf/project/ukrmol-in/ and http://www.tampa.phys.ucl.ac.uk/rmat/ .

0 Kudos
durgapal__shubham
710 Views

 

I checked before posting. i am getting fort .2 , 13,81,82,83 files when i run swmol3. and fort 18 and 144 files. from stage 1 output. this stage becomes input for stage 2.

It is in stage 2, i am getting segmentation fault in sword.f t  here the fort.2 file is not empty but 139.9MB !

the stage 1 output files are zipped.

stage 2 input file is attached

What changed are required. I understand its related to environment variables/ makefiles or compiler options. but i am unable to figure it out.

Can you pl suggest if i mentioned variables correctly in .bashfile  or wrongly written

ulimit -s unlimited
export OMP_STACKSIZE=500M

export PATH=$PATH:/opt/intel/bin
export PATH=$PATH:/usr/bin:/usr/local/bin

source /opt/intel/bin/compilervars.sh intel64
#source /opt/intel/bin/compilervars.sh ia32
export LD_LIBRARY_PATH=/usr/lib/:$LD_LIBRARY_PATH
export LIBRARY_PATH=/usr/lib:$LIBRARY_PATH

export LD_LIBRARY_PATH=/opt/intel/lib:$LD_LIBRARY_PATH

export LIBRARY_PATH=/opt/intel/mkl/lib/intel64:$LIBRARY_PATH

export MANPATH="/opt/intel/man"

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

export LD_LIBRARY_PATH=/opt/intel/mkl/lib/intel64:$LD_LIBRARY_PATH

what should i do ? kindly assists

shubham

 

 

0 Kudos
mecej4
Honored Contributor III
710 Views

I have to direct you again to the comments that I made in the last paragraph of #7. 

0 Kudos
jimdempseyatthecove
Honored Contributor III
710 Views

Segmentation fault is not necessarily a stack fault. Stack fault is usually reported as stack fault. Try running your program with either OMP_NUM_THREADS=1 or link in the OpenMP stubs library. IOW verify the serial.single thread version runs. Stack overflow can result from either the main thread stack overflow (linker option) .OR. created OpenMP thread stack overflow (environment variable setting).

Jim Dempsey

0 Kudos
Reply