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,962 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
Steve_Lionel
Honored Contributor III
1,140 Views

Not a lot of useful info here. One possible cause of this error, that is not at all obvious, is exceeding 2GB static code and data (even in 64-bit). If it was a library or path problem, you'd get a specific error about some DLL not being found.

Do you have very large COMMONs or module variables declared? Select the option for a link map, build the application, then ZIP the .map file and attach it to a reply here.

0 Kudos
Steve_Lionel
Honored Contributor III
1,140 Views

Oh, I will suggest editing your PATH to remove the older MPI folders.

0 Kudos
Bruce_Weaver
Beginner
1,140 Views

Hi,

 

The program does use a lot of space but we have the stack set to maximum size.  Also, sometimes it works and sometimes it doesn't...it seems that some invisible variable/path inside the compiler/VS/linker keeps flopping around.  Here is the map file.

0 Kudos
Bruce_Weaver
Beginner
1,140 Views

Hi,

Dropped the mpi references from the path &, for now(!), compiles seem to be working which I assume was a windows path length problem....now I'm returning to the problem that identical code indifferent directories is giving different answers.  I'll be interested if you see anything interesting in the map file.

thanks.

0 Kudos
mecej4
Honored Contributor III
1,140 Views

There can be any number of reasons why "identical code" in different directories may give different results. Data files read by the program may be different, you could be compiling with different compiler versions and compiler options, and you may be linking to different libraries; your program could be using variables without proper initialization; and, a more far-fetched reason: your program could be creating a magic number from the name of the directory, and using that number to seed an RNG!

You will have to bear the burden of narrowing down the problem. The map file that you provided is over 2500 lines long, and that may be a bit too much for humans to digest without spending an inordinate amount of time, unless one has strong ideas regarding what the code seeks to do and how it is expected to behave.

0 Kudos
Steve_Lionel
Honored Contributor III
1,140 Views

Bruce Weaver wrote:
The program does use a lot of space but we have the stack set to maximum size.  

Don't do that. Setting the stack size too large will cause exactly this symptom, as it reduces available space for code and data. What I usually recommend is enabling the option Fortran > Optimization > Heap Arrays > 0 (or /heap-arrays on the command line). This causes array temporaries to be created on the heap instead of the stack, reducing pressure on the stack. You can usually be safe to set the stack reserve size as high as 100MB, but I don't recommend going any higher.

0 Kudos
Bruce_Weaver
Beginner
1,140 Views

mecej4:

Probably not.  Data files are shared (outside the directories).  File compares show the code is the same and the compiler & linker options, including libraries, are the same.  The random number initializations are the same.  Moreover, the differences are always the same. 

What is worse, I can get the same version to give both the incorrect and correct results DEPENDING ON WHICH VERSION I ran just before running the problematic versions.  I have a 2 year-old version which, if I run it, most of the later versions will run correctly.  If I run my latest version, the problematic versions revert to bad results.  SO I'm pretty much convinced that something is remembering some characteristic between versions.  (Extra fun: the latest version only works on a dumb laptop...identical everything...I just copied the whole directory over.  That doesn't help on my main computer.)

Steve: I'll try what you suggest. As I read the description, zero will "always allocate them on the heap. If I use some number .gt. 0, does it matter what it is?  Thanks.

0 Kudos
Steve_Lionel
Honored Contributor III
1,140 Views

Just use zero for the Heap Arrays value - the situations where a nonzero value make any difference are so few (and pointless) as to not be worth thinking about. Make sure you also cut back the Stack Reserve value to no more than 100000000.

0 Kudos
JohnNichols
Valued Contributor III
1,140 Views

SQl Server and your combination of VS 2015 and Intel gives problems, this is why I had to switch to MySQL -- It all started with a recent update to SQL Server and it is a problem. Also switch to VS2017 Community is not a bad idea, the best idea is to send your code to someone you can trust like Steve and let them try it.

 

0 Kudos
JohnNichols
Valued Contributor III
1,140 Views

Unless it is the launch codes for ICBM's - in that case possibly Steve is not cleared

0 Kudos
mecej4
Honored Contributor III
1,140 Views

Bruce Weaver wrote:
What is worse, I can get the same version to give both the incorrect and correct results DEPENDING ON WHICH VERSION I ran just before running the problematic versions.  I have a 2 year-old version which, if I run it, most of the later versions will run correctly.  If I run my latest version, the problematic versions revert to bad results. 

All these symptoms strengthen the suspicion that some variables are being used without having been initialized. Bugs of this nature may remain hidden/unnoticed for years. Just this month, someone reported finding such bugs in the 45-year-old Eispack package on Comp.Lang.Fortran newsgroup.

0 Kudos
Bruce_Weaver
Beginner
1,140 Views

Hi:

Setting the heap & stack as suggested seems to help some but not all of the versions.  Running release with check:uninit doesn't show up any problems.  I wanted to check for uninit in debug but I'm back at not being able to run in debug mode as it can't seem to find the compiled debug version...although it is in the right place.  In an earlier version, the debug runtime uninit check turned up one in an Intel routine that I cannot, of course, correct.  sigh.

0 Kudos
Steve_Lionel
Honored Contributor III
1,140 Views

I can see no way that enabling the option to check for uninitialized variables would detect an issue in an Intel library routine. You may be confused by the way the traceback or debug break works where the error appears to be coming from the library routine used to report the error. Look one stack frame up to your code to see where the issue really is. In the debugger, use the Stack Frame dropdown to view the caller.

Are you saying that you still see "unable to start" after making the changes I suggested?

0 Kudos
JohnNichols
Valued Contributor III
1,140 Views

mecej4 wrote:

Quote:

Bruce Weaver wrote:

What is worse, I can get the same version to give both the incorrect and correct results DEPENDING ON WHICH VERSION I ran just before running the problematic versions.  I have a 2 year-old version which, if I run it, most of the later versions will run correctly.  If I run my latest version, the problematic versions revert to bad results. 

 

All these symptoms strengthen the suspicion that some variables are being used without having been initialized. Bugs of this nature may remain hidden/unnoticed for years. Just this month, someone reported finding such bugs in the 45-year-old Eispack package on Comp.Lang.Fortran newsgroup.

I work with a lot of very old Fortran code.  Undeclared variables are the greatest problem, particularly when the code comes from an academic source and has run "nicely" for a professor for years, and then you put it into Intel Fortran, Intel Fortran picks up a lot of errors that one did not know existed.   Hunting down these errors is really hard and tedious.  Last week's effort had an implicit none in every routine, except one and this had the bug, just looking at the code is a problem because you are not looking for the simple errors.

I appreciate your frustration, but if it was my code, I would try outputting everything to a dump file and look to see what appears odd, ie not declared or is set to wrong value, but you are dealing, except with me, with some of the best Fortran programmers in the world, if they are stumped, the problem is really hard.

Good luck

0 Kudos
Bruce_Weaver
Beginner
1,140 Views

Hi Steve,

The uninitialized error refers to a system timing routine.  The traceback is to the 'main', and a variable which are not ours.. It could be that we sent the routine an uninitialized value but it wasn't noticed until it got into the library routine(?).

Yes we are still getting unable to start/find complaints.  This has been a problem which has plagued us for years.  We just fuss around for awhile until it seems to find it.  The current version is that I compile a debug version successfully but when I go to run, it insists on trying to recompile (out of date) & immediately says it cannot find it. So there seems to be some sorta disconnect between compile & link & where it goes for execution.  The executable is sitting comfortably in the x64 debug directory.  If I try to run it from there, it complains that I do not have mkl installed (which I assume it finds when I run the same code in release mode). 

It may be helpful to note that if I run amplifier, I sometimes have to tell it where to go find the directory as the default isn't right.  I'm hoping there is an equivalent redirection capability for executable running from VS.

0 Kudos
gib
New Contributor II
1,140 Views

Do you see anything odd when you look at the exe with depends?

0 Kudos
mecej4
Honored Contributor III
1,140 Views

Bruce Weaver wrote:
The executable is sitting comfortably in the x64 debug directory.  If I try to run it from there, it complains that I do not have mkl installed.

The environment within which you attempt to run your EXE should have in PATH the directories of the runtime DLLs of the compiler and MKL. The PATH that you showed in #1 contains the directory containing the compiler DLLs, namely, ..redist\intel64_win\compiler.. , but not the MKL  DLLs, which should be in a directory such as <compiler/parallel_studio installation directory>\compilers_and_libraries_2019.1.144\windows\redist\intel64_win\mkl -- note the "mkl" at the end.

0 Kudos
Steve_Lionel
Honored Contributor III
1,141 Views

Look in the Debugging property page in VS. This is where you specify the Command to run (path to executable), any Command Arguments, Working Directory and any Environment variables you may want defined. As for redirection, you can do that in the Command property.

That you seem to get uninitialized variable errors in a timing routine makes me wonder if your program is corrupting the stack.

0 Kudos
Bruce_Weaver
Beginner
1,141 Views

I'm doubting that my code is to blame as I can get it to work on a naive computer by just moving the whole directory over.  Also works most of the versions work on other machines, other versions of VS (on other machines), etc.  My latest version of the code only works on one machine.  The machine-to-machine variation points, I think, to Microsoft/Intel issues.  I'll attend to the MKL problem; which I don't understand as I installed the MKL package.  I'll run that down tonight or tomorrow.

"Do you see anything odd when you look at the exe with depends?"  Sorry, I don't know what depends means.  Do you mean the callback stack or a specific tool?  I can look at it w/ Understand for Fortran but I don't expect anything especially interesting.

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 & the problem persists after hundreds of cycles.  I am, btw, making very heavy use of openMP.

thanks for your continued suggestions; they have been helpful so far & have improved, but not totally solved, the problems so far.

0 Kudos
gib
New Contributor II
1,070 Views

depends.exe is the Dependency Walker program.  http://www.dependencywalker.com/

It is a very useful tool for checking the DLL dependencies of executable code (i.e. .exe and .dll).   It will tell you which DLLs the program is trying to use, and if there are needed DLLs that it can't find. It's important that the PATH in operation when you run depends.exe is the same one that is in operation when you run the program.  Steve thinks stack corruption might be the problem, in which case depends will not help.  You should have it in your toolbox anyway.

Since you are using OpenMP, does the problem occur when you run in serial mode (single CPU)?

0 Kudos
Reply