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

another unable to start

Bruce_Weaver
Beginner
2,970 Views

Hi,

We've been having persistent 'unable to start' or can't find errors, even though the executable has been made and is correctly located.  The executable will not run stand alone; I suppose for wrong libraries??  Sometimes things are ok and then they switch back.  When not ok, debug version may run (incorrectly) but not release.  The forum seems to indicate this may be a PATH problem.  I'm using VS 15 & the latest Fortran 2019 update 1.  The software runs correctly on a laptop w/ very little on it.  I cannot seem to install Fortran on community VS 2017.  Don't really care.

Q1: Is there a tool in VS2015 to tell it where to look (like the one in Amplifier?)

Q2:  Here is my PATH; as far as I can tell, it seems benign and current.

Path=C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program Files (x86)\MSBuild\14.0\bin;C:\Program Files (x86)\MSBuild\14.0\bin;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\x86_amd64;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools;C:\Windows\Microsoft.NET\Framework\v4.0.30319;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\VCPackages;C:\Program Files (x86)\HTML Help Workshop;C:\Program Files (x86)\HTML Help Workshop;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Performance Tools;C:\Program Files (x86)\Windows Kits\10\bin\x86;C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\;C:\Program Files (x86)\Intel\..\..\intel64\libfabric\bin\utils;C:\Program Files (x86)\Intel\..\..\intel64\libfabric\bin;C:\Program Files (x86)\Intel\..\..\intel64\bin\release;C:\Program Files (x86)\Intel\..\..\intel64\bin;C:\Program Files (x86)\IntelSWTools\Advisor 2019\bin32;C:\Program Files (x86)\IntelSWTools\VTune Amplifier 2019\bin32;C:\Program Files (x86)\IntelSWTools\Inspector 2019\bin32;C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2019.1.144\windows\mpi\intel64\bin;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2018.2.185\windows\mpi\intel64\bin;C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2018.0.124\windows\mpi\intel64\bin;C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.4.210\windows\mpi\intel64\bin;C:\ProgramData\Oracle\Java\javapath;C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2018.0.065\windows\mpi\intel64\bin;C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.2.187\windows\mpi\intel64\bin;C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.0.109\windows\mpi\intel64\bin;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64_win\mpirt;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32_win\mpirt;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64_win\compiler;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32_win\compiler;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Windows\system32\config\systemprofile\.dnx\bin;C:\Program Files\Microsoft DNX\Dnvm\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\SciTools\bin\pc-win64;d:\Program Files (x86)\IDM Computer Solutions\UEStudio;C:\Program Files (x86)\IDM Computer Solutions\UltraCompare;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;D:\Program Files\PuTTY\;C:\Program Files\dotnet\
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC

 

The main use of this computer is to compile & run my software in Fortran so I don't mind dumping anything that is causing a problem.

I just spent a week fooling with my code only to discover it is not the problem.  Most appreciative of any help in this regard.  thanks.

0 Kudos
90 Replies
mecej4
Honored Contributor III
454 Views

Bruce Weaver wrote:
I have a couple possible places to look for uninitialized variables but the program is a markov chain simulation that cycles many times so, even if it started uninitialized, it would promptly become initialized.

For statically allocated variables, that is a somewhat reasonable assertion.

However, for dynamically allocated variables and, even more so, automatic and local variables allocated on the stack, that is not true at all.

Persistent use of uninitialized variables may give incorrect results, induce much slower convergence or divergence and, in general, yield unreliable results, cause poor performance and adversely affect the reputation of the authors of the code.

0 Kudos
JohnNichols
Valued Contributor III
454 Views

mecej4 wrote:

Quote:

Bruce Weaver wrote:

I have a couple possible places to look for uninitialized variables but the program is a markov chain simulation that cycles many times so, even if it started uninitialized, it would promptly become initialized.

 

For statically allocated variables, that is a somewhat reasonable assertion.

However, for dynamically allocated variables and, even more so, automatic and local variables allocated on the stack, that is not true at all.

Persistent use of uninitialized variables may give incorrect results, induce much slower convergence or divergence and, in general, yield unreliable results, cause poor performance and adversely affect the reputation of the authors of the code.

In a recent Bayesian Fortran Program for Dirichlet  distributions, a dynamically allocated variable caused a few hours of heart ache as I tracked it down -- very easy to miss and the havoc on the numerical analysis was bizarre behaviour.

mecej4 as usual is correct, assume the new Fortran compiler has now caught behaviour that used to be acceptable.

Happens all the time - used to be annoying - now it is just routine. I remember Powerstation Fortran broke so many of my programs I was months fixing the problems.

 

0 Kudos
Bruce_Weaver
Beginner
454 Views

Hi,

I reinstalled mkl w/o joy so I put the path in by hand as suggested and that, as well as some other tweaks such as dropping everything I couldn't find a use for from the path helped with the finding of the executables.  I'm still stuck with the bizarre problem of getting the wrong answers in the current versions unless I go back and recompile a two-year old version version (which always gives the right answers) & then return to the current version and recompile.  I've repeated this often enough that it is sop let me work on other issues on the current version (until it forgets & reverts to bad behavior).  When I go to the older version, I start it w/ a different instantiation of VS 2015/Fortran 2019v1.  Then return to the existing instantiation of the current one & recompile.   What could possibly be remembered across this procedure?!

I did set the compiler properties to initialize arrays & variables to zero but it just slowed the code way down & still gave bad answers. So, John, as far as I can tell all my dynamically allocated arrays are promptly filled.  What turned out to be your problem?  I'm assuming you used them before you filled them?

 

0 Kudos
mecej4
Honored Contributor III
454 Views

This is the 25th post in this thread, yet I see little movement in the direction of resolving the problems reported. I think that the reason for that is that we know few specifics, and there is far too little information to enable one to construct a bug demonstrator program from the descriptions that have been given. Furthermore, mixing up two different issues (1 - paths to MKL and other RTL DLLs from various versions of Intel Parallel Studio/Fortran Composer and 2 - the possibility of variables not having been initialized before use) makes things worse.

Let us try a different approach. Take the code below, which mere inspection will reveal to make use of uninitialized variables, and apply the same compiler options that you used on your large application about which you wrote. Can you get the compiler to catch the uninitialized variable usage?

program klobber
implicit none
integer s
!
call sub1(s)
print *,s
call sub2(s)
print *,s
call sub3(s)
print *,s
end program

subroutine sub1(s)
implicit none
integer, intent(out) :: s
integer :: i, x(10)
do i=1,9,2
   x(i) = 2*i-3
end do
s = 0
do i=1,9,2
   s=s+x(i)
end do
return
end subroutine sub1

subroutine sub2(s)
implicit none
integer, intent(out) :: s
integer :: i, x(10)
do i=2,10,2
   x(i) = 2*i+3
end do
s = 0
do i=2,10,2
   s=s+x(i)
end do
return
end subroutine sub2

subroutine sub3(s)
implicit none
integer, intent(out) :: s
integer :: i, x(10)
do i=2,10,2
   x(i) = 2*i+5
end do
s = 0
do i=1,10
   s=s+x(i)
end do
return
end subroutine sub3

0 Kudos
gib
New Contributor II
454 Views

Did you look at your program with Dependency Walker?

0 Kudos
Bruce_Weaver
Beginner
454 Views

mecej4:

no, f90 2019v1 does not detect any unitialized variables when selected in runtime diagnostics.  

0 Kudos
Bruce_Weaver
Beginner
454 Views

gib: I've started w/ dependency walker.  In the static case all that are missing in the one that gives bad answers is the same as the one that gives good answers. Most seem to be API-MS-WIN-Core-WINRT ... DLLs.  There are a few others I have not yet tracked down.  I have not figured out how to run it dynamically.  A very odd occurrence: I ran a version which never works correctly in Amplifier & it worked correctly the first time but never again after that....weird.  I should add that I load an allocatable file that is 252MB; but I'd think in x64 that should not be a problem.

0 Kudos
mecej4
Honored Contributor III
454 Views

Bruce Weaver wrote:

no, f90 2019v1 does not detect any uninitialized variables when selected in runtime diagnostics.  

Thanks for trying out the code. If you look at SUB3, you will note that only the elements x(2), x(4),..., x(10) are defined in the first DO loop. When the second DO loop is executed, x(1), x(3), ..., x(9) are used even though they have not been previously given values.

My question, then: is it possible that you have this type of bug in your large code? There exist compilers that, when asked, are able to trap such errors -- Lahey-Fujitsu, NAG and Silverfrost.

0 Kudos
Steve_Lionel
Honored Contributor III
454 Views

Have you tried temporarily disabling any antimalware program you have enabled? The other thing I like to suggest is to boot into Safe Mode and see if the behavior reproduces.

0 Kudos
Bruce_Weaver
Beginner
454 Views

I had thought of silverfrost since it is reputed to have good diagnostics but they do not support OpenMP which is central to this program.  The only malware program I use is MS Security Essentials, which I have assumed to be benign in this regard.. BTW, Steve, installing various recent versions of MKL did not put the libraries in the path...on a couple machines.  I added it to the path manually, as suggested by mecej4.  My central concern at this point is that these programs give the correct answers sometimes and not other times; apparently depending on what ran on the machine previously.  Since the program cycles millions of times, any uninitialized issue must persist.  I have set the compiler choice to initialize all variables and arrays to zero, which slows the execution time (all inside OpenMP) which might be suggestive that it may be a initialization issue.  I guess I will have to comb through the code with the debugger by hand.

0 Kudos
Steve_Lionel
Honored Contributor III
454 Views

The Intel performance libraries (including MKL) do not get added to PATH when you install. Your description of the symptoms is changing. I'm more concerned about the failure to even start the program. The inconsistent results are almost certainly the work of a coding error in your application.

0 Kudos
Bruce_Weaver
Beginner
454 Views

I think it is almost certainly not.  We've had this issue for years with various programs, much to our frustration.  How could the code obfuscate the location of executable, which is present in the appropriate location?  Just some of the time?  If you mean that something in our code confuses the way in which VS/Intel keeps the locations, I could believe that...but it seems to me that neither should allow that to happen.  BTW, why  doesn't the path to the MKL dlls get added to the path?  Is that the only Fortran library that is not added?  I've just been checking the /Qmkl:parallel option.  Has it been ignored all these years?

0 Kudos
gib
New Contributor II
454 Views

Re. DW: "Most seem to be API-MS-WIN-Core-WINRT ... DLLs.  There are a few others I have not yet tracked down."  DW usually reports some DLLs as missing that can be ignored, since they will in fact be located when the program executes.   "I have not figured out how to run it dynamically."  Sorry, I don't know what you mean by this.

0 Kudos
Bruce_Weaver
Beginner
454 Views

My understanding is that it has a static mode: it just looks at the executable file & a mode that looks for what it uses as it runs, that they call dynamic dependencies which will detect dependencies that are only loaded during execution.

0 Kudos
IanH
Honored Contributor II
454 Views

Dependency Walker unfortunately does not understand API sets (the API-MS-WIN-Core-xxxx stuff) that have been introduced with more recent Windows versions, hence the errors.  There are alternative utilities that have been updated - for example https://github.com/lucasg/Dependencies. ; I don't have a lot of experience with them.

There are duplicate paths within your PATH.  Why?  Excessive path length on some versions of Windows in some situations causes all sorts of grief.

Your path also references multiple Fortran compiler versions, and has some paths with relative references in the middle of them.  This doesn't appear to be a sane configuration.

0 Kudos
gib
New Contributor II
454 Views

"My understanding is that it has a static mode"  This news to me, and I've been using DW for years.  Given a .exe or .dll it traces all the DLL dependencies, using the PATH that is in operation.

By the way it is a good idea to use a path editting program to clean up the PATH env variable.  I use Path Editor from Redfern Software, I believe there are others.

0 Kudos
Steve_Lionel
Honored Contributor III
454 Views

Bruce Weaver wrote:

BTW, why  doesn't the path to the MKL dlls get added to the path?  Is that the only Fortran library that is not added?  I've just been checking the /Qmkl:parallel option.  Has it been ignored all these years?

MKL does not have a "Fortran library". The reason given to me was that the MKL team believes that their users want to point to a specific version of MKL and not use the latest installed on the system. This certainly does complicate issues for people starting to use MKL, and, inexplicably, there is no mention of this in the MKL documentation. I don't understand it and consider it user-hostile. 

The DLL location is completely separate from how you BUILD an application. /Qmkl adds the selected set of MKL libraries (and include paths) to the build.  PATH doesn't come into play until you run the application, at which point only Windows' mechanism for finding DLLs is used. Note that if you use the compiler build environment command prompt, the MKL DLLs get added to PATH for that session by the startup script.

0 Kudos
LRaim
New Contributor I
454 Views

So many post with no solution !!.
I do not know if your problem is linked to the PATH variable. If so I would suggest to launch the .exe using a .bat file and including a PATH= variable redefinition instead of relying on the global PATH variable. You may add one library step by step and see what happens.

 

0 Kudos
Steve_Lionel
Honored Contributor III
454 Views

So many posts without a reproducible example, and a constantly shifting description of symptoms. So far I don't see that any of the symptoms listed so far are related to PATH.

0 Kudos
Bruce_Weaver
Beginner
452 Views

Steve: you're right, I've mixed two problems in this discussion. I was pursuing the issue of the same code giving two different answers when I was stymied by not being able to run the code at all.  The latter problem seems to have abated either because of the path changes or, more likely, because I followed your suggestion and backed off the stack size.  This let me return to the basic problem I was pursuing: namely, the identical code and compiler/linker options behave differently depending on what was run previously on the computer.  It's about 4000 lines of complicated, mostly OpenMP code, so it is very resistant to being stripped down to a 'reproducible example'.  I've tried to cut it apart but most of the code has tight interdependencies.  What I do know is that running a two-year old, earlier version of the program from a different directory 'resets' things so that it will produce correct answers for a bit.  I have no idea how that could happen & it seems like a MS/Intel issue as my user code should not be able to do what it is apparently doing.  I understand that w/o a small example program, y'all are very limited in response but, if I could do that I might not even have to ask for help...or, at least, pose a much more specific question to the appropriate Intel team.

0 Kudos
gib
New Contributor II
452 Views

Since OpenMP multiplies code complexity, and sometimes makes debugging tricky, I think it has to be a suspect.  Apologies for asking this again - is it possible to limit your program to a single CPU, i.e. to run in serial mode?

0 Kudos
Reply