Problem with "forrtl" when running bash script on open terminal window

Farrokh_A_ · ‎07-14-2014

I wrote a bash scrip that download files from internet and then run a software called Wavewatch (which is compiled with Intel Fortran Compiler) to do some process using downloaded files. The problem is that when I run the script using crontab (which runs in background without any open terminal window), everything goes well, but when I run the command manually in a Terminal window, a software module (called ww3_outp) returns an error complaining about writing problem of /dev/pts/0 looks like this:

forrtl: severe (38): error during write, unit 6, file /dev/pts/0
Image              PC                Routine            Line        Source             
ww3_outp           00000000004AFEDB  Unknown               Unknown  Unknown
ww3_outp           0000000000408A6A  Unknown               Unknown  Unknown
ww3_outp           0000000000408236  Unknown               Unknown  Unknown
libc.so.6          000000347D81ED1D  Unknown               Unknown  Unknown
ww3_outp           0000000000408129  Unknown               Unknown  Unknown

I looked to /dev/pts/ and found that with each instance of Terminal window a file named by a number (0,1,2,...) is produced which can't be edited or deleted even with root permission. It seems so weird, any idea?

Steven_L_Intel1 · ‎07-14-2014

It looks as if there's a write to unit 6 (stdout). Perhaps you should redirect stdout to /dev/nul when you run the program?

Farrokh_A_ · ‎07-14-2014

Thanks for the reply Steve, but I won't be able to see the output on the screen if I do what you said. Also, I should mention that many other modules send their output to the stdout without any problem. Actually, the problem occurs when the mentioned module already sent about 3000 lines of output to the stdout!!! By the way, I won't have any problem if I compile the module with gfortran!

Steven_L_Intel1 · ‎07-14-2014

Well, there's something about the device that causes an error to be returned. Unfortunately there isn't an additional clue as to what the error is, though you might try calling GETLASTERROR() (not GETLASTERRORQQ) from IFPORT when the error occurs and see if a more detailed error code is available.

Farrokh_A_ · ‎07-15-2014

Would you please tell me how to do that, I'm new to Fortran Compiler issues ;p

Ron_Green · ‎07-15-2014

Does the cron job run as the same UID as you use when you run from the terminal window?

Are you physically at the server or are you logged in remotely?

What linux distribution and version is this?

Have you tried logging in as another user and trying the same command?

What is your default shell? echo $0 will return this.

ron

Steven_L_Intel1 · ‎07-15-2014

On reconsideration, the GETLASTERROR info will probably not be useful. I find it interesting that it works for a while and then fails after 3000 writes.

Farrokh_A_ · ‎07-16-2014

Ronald W Green (Intel) wrote:

Does the cron job run as the same UID as you use when you run from the terminal window?

Are you physically at the server or are you logged in remotely?

What linux distribution and version is this?

Have you tried logging in as another user and trying the same command?

What is your default shell? echo $0 will return this.

ron

Thanks for your reply, I answer you questions respectively:

1) yes

2) I'm at my desktop computet

3) CentOS 6.5 64bit

4) yes, I also tried to run the script as root logged in

5) my default shell is bash

Ron_Green · ‎07-16-2014

Do you know how much memory this application will consume? can you run 'vmstat 1' in one window while kicking off the cronjob to see if this app is using memory close to the amount of physical RAM? Is it paging or swapping?

Are all the file systems used local disk or NFS, or what? You're not using a parallel file system by chance are you?

It's very odd that the cron runs but the interactive shell does not. Have you checked your aliases and dot files for anything odd that would affect an interactive shell and not a cron shell?

Do other simple Fortran jobs run OK?

ron

Ron_Green · ‎07-16-2014

also, how many files are open simultaneously?

What is the value of 'open files' from 'ulimit -a', like this:

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 15853
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) unlimited
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Farrokh_A_ · ‎07-17-2014

Ronald W Green (Intel) wrote:

also, how many files are open simultaneously?

using "ulimit -a":

open files (-n) 1024

Ron_Green · ‎07-17-2014

Can I assume then that you do not open more than 1020 or so files in your program? You didn't say how many files the program opens at any one time or how many files total are processed.

Also, have you tried simple programs that print to stdout? Something like this maybe:

program writestuff
implicit none
integer :: i

do i=1,1000000
  print*, "writing to stdout"
end do

end program writestuff

Also - unit numbers you use in the OPEN(s) - are you using unit numbers greater than 10? That is, units attached to disk files. Obviously you may be opening 5 or 6 for stdin stdout

ron

Since no one else has reported something like this and I don't have your program I'm just guessing about common problems.

Farrokh_A_ · ‎07-17-2014

I wrote and ran the code you provided, and all went fine without any problem.

I think that you are right about using unit 5 in stdout. I looked into the source code but I couldn't change the stdout unit id, it seems that the unit id parameter is linked to another file which is a compiled file. I should also mention that the code works on Ubuntu flawlessly! Maybe there is smething wrong with CentOS!

Ron_Green · ‎07-25-2014

CentOS is fine, we have a number of servers here with it, no problems. It could be THAT installation of CentOS. unit 5 for stdout is fine, nothing wrong with that. It is possible the CentOS installation has corrupted device drivers for the terminal I suppose.

So your application calls into function(s) in a pre-compiled library? Is it a .a or a .so library? Was this library built for Intel Fortran, gfortran, Absoft or what compiler? and what version of the compiler or how old is this library? That could be the problem. The library has to be built with Intel Fortran to work with your program calling it. Also, the versions should be either the same or close.

ron

TimP · ‎07-25-2014

unit 5 comes pre-connected to stdin. Earlier in the thread unit 6 was mentioned.

Steven_L_Intel1 · ‎07-25-2014

Please don't write to unit 5, unless you have connected it to a file. As Tim says, unit 5 is preconnected to stdin and you shouldn't write to that.But it is clear from the original error message that unit 6 is being used.

Farrokh_A_ · ‎07-26-2014

CentOS is fine, we have a number of servers here with it, no problems. It could be THAT installation of CentOS. unit 5 for stdout is fine, nothing wrong with that. It is possible the CentOS installation has corrupted device drivers for the terminal I suppose.

So your application calls into function(s) in a pre-compiled library? Is it a .a or a .so library? Was this library built for Intel Fortran, gfortran, Absoft or what compiler? and what version of the compiler or how old is this library? That could be the problem. The library has to be built with Intel Fortran to work with your program calling it. Also, the versions should be either the same or close.

The entire software (Wavewatch III Model) should be compiled from source. I compiled it with Intel Fortran and MPICH (mpif90) which itself has been compiled with Intel Fortran (same as the first one) as well, both on one instance of the operating system which here is CentOS 64bit. I mean the compiler, version and operating system are all the same for any component of the software. I've done the same thing on Ubuntu and the software works flawlessly, so I was thinking that maybe CentOS could be the problem!

unit 5 comes pre-connected to stdin. Earlier in the thread unit 6 was mentioned.

The problem occurs sometimes for UNIT 5 and sometimes for UNIT 6! And again that is why I think that maybe CentOS is involved somehow!