Topic: Call to system function

General question regarding the use of the system call as per the examples below:
            iresult=system(trim(ShellCommand))
            call system(trim(ShellCommand),iresult)

Is there any preference on whether one uses the first or second form of the system call? I am asking because I just discovered the second form after reading the GNU documentation on this feature and learning that it can be a function or a subroutine call. I was using the first form extensively and kept running into memory segmentation faults and could not understand why (see previous forum threads by me). These memory faults would crop up occasionally, in different run instances and different machine; seemed to be completely random and rare.

After finding out about the second form above, I switched the code over to the call system form. The instance that was causing problems now doesn't exhibit the memory fault but that really means nothing as it is a new instance and problem with differing memory usage. I am just wondering if there is something know to be different in those two system calls methods?

FYI, I am still using SF 2.41, build 2559 and GNU 7.2.0 FORTRAN.
Thanks,
Rod

Re: Call to system function

Rod,

Either should be fine, and I'm not sure why there is a crash on the first.  I would suggest, however, switching to EXECUTE_COMMAND_LINE, which has a form similar to the subroutine call you've shown. This call is part of the Fortran standard and would be portable across compilers.

Jeff Armstrong
Approximatrix, LLC

Re: Call to system function

Thanks Jeff.

Will EXECUTE_COMMAND_LINE work with a FORTRAN90 compilation? I see this system call is a FORTRAN 2008 feature. I guess I can give it a try.

Thanks again.

Rod

Re: Call to system function

Rod,

You're already using a "GNU Extension," so the EXECUTE_COMMAND_LINE call would be more reliable if you ever want to try another compiler.  GNU Fortran will allow Fortran 2008 intrinsic procedures in basically any Fortran source code unless specifically instructed to conform to a different standard.

Jeff Armstrong
Approximatrix, LLC

5 (edited by grogley 2020-02-27 14:08:29)

Re: Call to system function

I tried the EXECUTE_COMMAND_LINE call in my code and it crashes too with the same memory segmentation fault. This problem has been going on for years now and I find no way to figure it out. Clearly as I have indicated before, it does not occur if I compile without the OpenMP extensions. However, this makes no sense to me since all the code is running single threaded when the system calls happen.

This problem also seems to only happen with certain parameter conditions. The simulation I am running when it crashes has 5001 particles but if I run it with fewer or more, it may not crash. I am just not getting what is happening.

Since we have rehashed this before, I don't expect to get any answers. Maybe an upgrade will help. Sigh.

Rod

PS. Just to follow up, I run the same simulation that crashes on one machine and run it on my development system but this time with even more frequent calls to the subroutine that has the EXECUTE_COMMAND_LINE calls and it does not crash.

Re: Call to system function

Rod,

I was unaware that OpenMP was being used. The crash is almost certainly caused by an insufficient stack.  Try adding the following flag to the Linker box in Compiler Flags under Project Options:

-Wl,--stack,256000000

The above will cause the stack to be 256MB for each thread (so be aware of memory issues).  OpenMP changes how some allocation occurs, and stack space can be exhausted quickly.  Let me know if the above works.

Jeff Armstrong
Approximatrix, LLC

Re: Call to system function

Jeff,

I already have a stack allocation as per my option:

Wl,--stack,150000000; not as much as your suggestion but seems to be more than adequate. For example, the offending task that would crash with only a total memory footprint of 5.1 MBytes as per task manager. I routinely run this with 10 times the number of particles without incident. I have one running with 50,000 particles and it only uses 14 Mbytes, so I don't think this is a stack problem (note I changed my code to allocate the arrays sizes at run time to be the exact size needed). As I said before, you and I have had several exchanges about this in the past and this issue still comes back to bite me. Ugh.

That all said, I downloaded the SF load for R3 in trial mode, compiled my code and exchanged the code on the machine that was crashing. The new code breezed right through the crash point and is still running. I am causously optimistic that this will help to rid me of this scourge. I will run that code for a few days to be sure and if all is well, I have convinced my CFO (read the wife) that I need to buy a new license for the new version.

FYI, here is my R 2.41. Makefile if you are interested:

#
# Automagically generated by Approximatrix Simply Fortran 2.41
#
FC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gfortran.exe"
CC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gcc.exe"
AR="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\ar.exe"
WRC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\windres.exe"
RM=rm -f


OPTFLAGS= -O3 -fgraphite-identity -floop-interchange -floop-strip-mine -floop-block -floop-parallelize-all -mtune=native

SPECIALFLAGS=$(IDIR)

RCFLAGS=-O coff

PRJ_FFLAGS= -fopenmp

PRJ_CFLAGS=

PRJ_LFLAGS=-Wl,--stack,150000000 -lgomp

FFLAGS=$(SPECIALFLAGS) $(OPTFLAGS) $(PRJ_FFLAGS) -Jmodules

CFLAGS=$(SPECIALFLAGS) $(OPTFLAGS) $(PRJ_CFLAGS)

"build\riod.o": ".\riod.f90"
    @echo Compiling .\riod.f90
    @$(FC) -c -o "build\riod.o" $(FFLAGS) ".\riod.f90"

clean: .SYMBOLIC
    @echo Deleting build\riod.o and related files
    @$(RM) "build\riod.o"
    @echo Deleting default icon resource
    @$(RM) "build\sf_default_resource.res"
    @echo Deleting riod.exe
    @$(RM) "riod.exe"

"riod.exe":  "build\riod.o" "build\Riod-MP-F90.prj.target"
    @echo Generating riod.exe
    @$(FC) -o "riod.exe" -static -fopenmp "build\riod.o" $(LDIR) $(PRJ_LFLAGS)

all: "riod.exe" .SYMBOLIC

Re: Call to system function

Rod,

There is the possibility that the OpenMP library we had been providing was not properly sizing the stack on subsequent threads, making the linker flag useless with OpenMP.  I seem to remember having to fix that issue at some point, but I may be mistaken.  Let me know if it works with the latest version.

Jeff Armstrong
Approximatrix, LLC

Re: Call to system function

Hi Jeff,

I have done a fair amount of testing with the new version. I have not seen the specific problem reported earlier but it is too early to really tell. There is still another issue that has me perplexed that is probably related but I am not sure.

Specifically, I run my program in a command prompt that I start with batch program which opens the CMD.EXE window with the Start command. Here is in essence the command I start with:

start "N0x00ff_Program" /low  /affinity 0x00ff program.exe

However, sometimes, obviously not always, this start method will close out immediately after starting. I notice most on my Windows 10 machine. If I open a static CMD prompt with the same affinity restrictions, the program will run just fine. I am not sure what could be causing this.

In any event, I will be upgrading my license to SF R3 shortly. Thanks for your support.

Rod