Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
1 View

environment and stack size

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
Highlighted
Valued Contributor I
1 View

This is a backtrace from a

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

0 Kudos
Highlighted
1 View

thanks Mr Juergen.

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
Highlighted
Valued Contributor I
1 View

No, the libraries are found.

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

0 Kudos
Highlighted
1 View

The unknown(s) mean the line

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
Highlighted
1 View

@ jimdempseyatthecove

0 Kudos
Highlighted
Black Belt
1 View

I think that you will end up

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
Highlighted
1 View

mecej4

 

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
Highlighted
Black Belt
1 View

I have to direct you again to

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

0 Kudos
Highlighted
1 View

Segmentation fault is not

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