VisualFortran compiler throws Windows exception when ending Devenv

[peter_stevens]

Using VF 10.1.4156.2005 in conjunction with VS2005 compiles a series of projects but at the end of the fortran library build phase and before the fortran relink (exe) phase, for which a new devenv is started, the first devenv throws a Windows popup and halts the build process until the popup is acknowledged. The buildis otherwise successful.
The aspect that seems to be central to this (new) behaviour was when the project build order dependency was changed slightly to force the building of some common modules prior to other projects.
This behaviour exists whether doing a GUI build or a batch file build. the difference is that for a GUI build, you are unaware of the problem until you quit the GUI after the successful build is done.

Windows Application log contained the following detail:
Faulting application devenv.exe, version 8.0.50727.762, stamp 45716759, faulting module vfproj.dll, version 10.1.4156.2005, stamp 479cd907, debug? 0, fault address 0x0002e3df.

[Les_Neilson]

Quoting - peter.stevens

Using VF 10.1.4156.2005 in conjunction with VS2005 compiles a series of projects but at the end of the fortran library build phase and before the fortran relink (exe) phase, for which a new devenv is started, the first devenv throws a Windows popup and halts the build process until the popup is acknowledged. The buildis otherwise successful.
The aspect that seems to be central to this (new) behaviour was when the project build order dependency was changed slightly to force the building of some common modules prior to other projects.
This behaviour exists whether doing a GUI build or a batch file build. the difference is that for a GUI build, you are unaware of the problem until you quit the GUI after the successful build is done.

Windows Application log contained the following detail:
Faulting application devenv.exe, version 8.0.50727.762, stamp 45716759, faulting module vfproj.dll, version 10.1.4156.2005, stamp 479cd907, debug? 0, fault address 0x0002e3df.

We have the same sort of problem. We have a "build" machine dedicated to rebuilding our systems (current and development) every night via a series of batch files. The current system stops twice, (except for today when it has stopped just once) and the development system stops several times (~12 times) We have many solutions with multiple projects some of which are mixed language. We have Debug and Release configs then we have 2D/3D Debug and Relase and for development Win32 and X64 versions of those configs. There does not seem to be any consistency onwhich configit stops. The same batch process on my pc runs without problem! Every now and again the places at which it stops changefor no apparent reason (as mentioned above).
Clicking the "restart Visual Studio" box off and clicking "don't send",the process resumes and the resulting exes all work fine. We used to click "send" but never ever had any response from Microsoft and so we have become used to it happening.

Sometimes it is just good to know that you are not alone.

Les

[Steven_L_Intel1]

Just as a point of clarification - the compiler isn't doing anything here, it's Visual Studio and the Fortran project system that is failing for you.

I don't understand what you mean when you say "a new devenv is started". Can you clarify that? Typically, when you have a solution with multiple projects, only one instance of devenv.exe is running.

The version of Intel Fortran you are using is two releases old at this point, but I can't say if the current version would resolve the problem you're seeing. It might.

Is this problem completely reproducible for you? Are you willing to provide to us a ZIP file of your projects/solutions and everything needed to reproduce the problem?

[Les_Neilson]

Quoting - Steve Lionel (Intel)

I don't understand what you mean when you say "a new devenv is started". Can you clarify that?

The dialog box that appears when VS halts,has a tick box asking "Restart Visual Studio" the default is "on". If one clicks the "send" or "don't send" buttons (or presses the enter key) without unchecking the box then a new instance of Visual Studio is started. I presume this is whatPeter means.

Les

[Steven_L_Intel1]

He said this happens before the error, so I think it is something else.

[peter_stevens]

Quoting - Steve Lionel (Intel)

He said this happens before the error, so I think it is something else.

The version of VF is fixed to vendor compatability, so for us at present, 10.1.xxx is the only choice.
Regarding questions re 2nd instance of Devenv, it is coming from the driving Sysbuild script where we "build" the C library, then the fortran library and finally doing the relinking by seperate devenv that run sequentially.

Each of these is of the form (in a batch file) ::
devenv/useenv mycode_libsmycode_c_libs.sln /build %BuildTarget% /useenv
devenv/useenv mycode_libsmycode_fortran_libs.sln /build %BuildTarget% /useenv
devenv/useenv mycode_libsmycode_exes.sln /build %BuildTarget% /useenv

So in my case, the first goes thru without issue,
the 2nd devenv throws the popup at the completion of all the lib projects (and waits for manual intervention)
then the 3rd devenv runs and completes without issue.
Les is right, the default crash-restart causes a VS (GUI) to start up, so I just quit it if I forget to uncheck the tickbox but this is not the 2nd instance I am describing. Hope this makes sense.

In my situation, the issue seems to be solid and always seems to behave the same, except the crash memory location seems to drift from build to build (but may depend on how many projects are in the build, with some being skipped while I attempted to find a cause).

One aspect that I can now advise is that one of the popup causes can be fixed by removing the forced project dependencies and instead re-ordering the file sequence (text) in the sln file so the "natural" build order is correct. However this approach has not fixed another project from causing the popup situation. Currently I do not have a workaround for this one apart from manual intervention3hrs after sysbuild kickoff.
Although I did initially detect two causes for the popup crash, I always only get the one popup at the end.
Unfortunately it would be near impossible to zip and send the code due to vendor libraries and environment aspects and the sequence demands that the C parts be done before the fortran.

[Steven_L_Intel1]

You can install the IDE integration for version 11.1 and still use the 10.1 compiler - you'll have to go into Tools > Options > Intel Fortran > Compilers and select the 10.1 compiler.

I don't think there's much more I can suggest for you.

[peter_stevens]

Quoting - Steve Lionel (Intel)

You can install the IDE integration for version 11.1 and still use the 10.1 compiler - you'll have to go into Tools > Options > Intel Fortran > Compilers and select the 10.1 compiler.

I don't think there's much more I can suggest for you.

Thanks Steve. I will keep that in mind and may try 11.1on a test system.
Some more updates : I reshuffled the projects order in the (text) lib sln file, in particular placing the remaining troublesome projects toward the end of the sysbuild sequence and .... no popup crash. So maybe the reshuffling of the build order (without using the dependency option) works around whatever the issue is. But alas, I have only done 1 build; will take a few in a row before I can declare success.

For Les, one issue (like yours) was advised to us as being because we were building too many projects in a single sln. We used to build all C and F in the one sln and the vendor suggested we could be running out of resources. Our option was to split the libs sln into two (as I described earlier) and this arrangement has been good for a year until now. Good luck with your situation.

Thanks chaps for your input.

[onkelhotte]

Quoting - Steve Lionel (Intel)

You can install the IDE integration for version 11.1 and still use the 10.1 compiler - you'll have to go into Tools > Options > Intel Fortran > Compilers and select the 10.1 compiler.

I don't think there's much more I can suggest for you.

It would be great if Intel would release the IDE integration seperate from the compiler or the license youve got.

My license just expired andI do not need the new functionality of the 11.1.x compiler. But whenwe couldinstall a bugfixed version of the integration, it would solve a few problems here...

Markus

[Steven_L_Intel1]

You can install the integration from a newer compiler and use an older compiler version. We don't separate out the installs, and the integration's support of older compilers is limited to two versions back.

[jimdempseyatthecove]

Peter, Les, Steve,

I used to have a similar problem with a smaller solution with 13 projects and ~700 files.

The problem had to deal with the dependency checker, my projects as I thought I wanted them layed out, and the quirky nature of IVF relating to module files where it builds a precompiledheader (foo.mod) and builds the object files for those modules if code/data present (foo.obj).

This is not a complaint about IVF, I have my situation under hand.

The problem was it is easy to create a circular dependency list between a well used .mod file and the .obj files which might be packaged into the same library (for convenience).

In my situation, I havesmall header used in just about everything else. This file contains common type declarations, some initialized data, but no code (no contains).

This header used to sit in a generalized project that I have for my commonly used module files. These modules are built into corresponding .mod files and the resultant objs packaged into a static library.

The problem was when this common module was compiled as part of the generalized mod files project it created a circular reference. Or should I say occasionally created a noticeable circular reference. Depending on the build sequence with multi-threaded build it would on occasion result in being circular or not.

The fix was to extract this common mod and place into project of its own and now builds a library containing that lone file. The dependencies now are never circular.

Jim Dempsey

[peter_stevens]

Quoting - jimdempseyatthecove

Peter, Les, Steve,

I used to have a similar problem with a smaller solution with 13 projects and ~700 files.

The problem had to deal with the dependency checker, my projects as I thought I wanted them layed out, and the quirky nature of IVF relating to module files where it builds a precompiledheader (foo.mod) and builds the object files for those modules if code/data present (foo.obj).

This is not a complaint about IVF, I have my situation under hand.

The problem was it is easy to create a circular dependency list between a well used .mod file and the .obj files which might be packaged into the same library (for convenience).

In my situation, I havesmall header used in just about everything else. This file contains common type declarations, some initialized data, but no code (no contains).

This header used to sit in a generalized project that I have for my commonly used module files. These modules are built into corresponding .mod files and the resultant objs packaged into a static library.

The problem was when this common module was compiled as part of the generalized mod files project it created a circular reference. Or should I say occasionally created a noticeable circular reference. Depending on the build sequence with multi-threaded build it would on occasion result in being circular or not.

The fix was to extract this common mod and place into project of its own and now builds a library containing that lone file. The dependencies now are never circular.

Jim Dempsey

Jim, I think your detail is spot on. In my situation, the problem arose with the introduction of a new module in a common project space that was used by a number of related projects and breaking the (use of) forced dependencies avoided a circular thrashing.
I have now done several full Sysbuilds and no more crashes/popups (and all depedencies removed).
I take note of your suggestion re module placement, and that maybe an own project to handle such things may be a better way. Thanks.

[jimdempseyatthecove]

Peter,

I am glad to be of assistance. I've spent countless of hours relating to DevEnv problems and am happy to pass on any information that will be helpful in reducing your wasted effort. (VS 2005)

FWIW there used to be a similar problem with debugging.

1) place break point at point of interest
2) F5
3) DevEnv crash prior to startup
...
1) place break point at point of interest
2) F5
3) makes it to break point
... 10 to 20 minutes into difficult debug situation
Unexplained DevEnv crash

Both crashes related to attempt to write to location 0x0000005 or some place near.

Dissassembly window shows nothing of the sort.

In attempting to track down the 1st situation (crash on startup) I found

Step into the Dissassembly (into C startup code), then stepping through (over) startup and into call to main
then the program ran as it should. After a few times, I got the startup down to a few keystrokes.

The above is no longer happening for me. But when it did, I noticed that when you delete all your projects and solutions then re build them that the problem goes away - at least for some period of time.

With the newer revisions if IVF the problems seemed to go away. I do not think it was IVF but rather something weird inside DevEnv relating to a file in use, error message suppressed, but buffer or memory mapped file pointer not setup, then when accessing the missing data, GP halt referencing location 0x0000005. This may have been related to InteliSense. You will find other references to InteliSense and unexplained crashes of Devenv when mouse hovers over word with umlauts. VS 2005 does have its problems. I don't have a pressing urge to update to VS 2008.

Jim Demspey

[Steven_L_Intel1]

The umlaut issue was ours.

[Les_Neilson]

Jim et al,
Thanks for the pointers of where to look.
Normally I would have insisted thatthere areno circular dependencies but I would rather be sure than wrong :-( so I will check. As regards Solution/Project complexity, again I wouldn't have thought it was a problem. Some of the "pauses" occur in solutions with onlyone project with four configurations(Debug/Release Win32/X64)whilst another more complex solution with multipleconfigs (mixed language 4 projects debug/release win32/x64) sails through without a problem but ... again I will check in more detail. Also it halts on only one of the configs in any particularsolutionsoit canhalt on debug and then be followed by the release config(or vice versa) which compiles and links without problem. The batch process first builds all of the Win32 configs then starts the X64 batch build.Most of the halts are in the X64 build.

Itdoes seem to display Heisenbug properties, with configs which halted suddenly working ok and new configs now halting. Of course it may be restricted to this one particular pc (our overnight build server) Although we all have our own copy of the source tree (we use sourcesafe for version control) I copied the full source tree fromthe build machine,including all the batch files, to my pc and did a full rebuild without problem.
As far as I know other developers here have not had this particular problem (other problems yes but not this one) but not everyone does regular full rebuilds - I often do in order to catch any problems plus I am often used as the "Guinea Pig" to test new versions of VS / IVF :-)

Anyway it is a nuisance but not a show stopper (for us)

Les

[peter_stevens]

Quoting - Steve Lionel (Intel)

You can install the integration from a newer compiler and use an older compiler version. We don't separate out the installs, and the integration's support of older compilers is limited to two versions back.

Steve, I finally got around to installing IF11.0 and set compatibility for 10.1 as you suggested.
Unfortunately, while this may have addressed the dependencies build issue, IF11.0 also wanted to upgrade all 240+ vfproj files for Version "11.0" and various project optimization and CPU style setting changes also.
Perceived to be too risky and time consuming to to pursue and re-test, so have unfortunately reverted back to IF10.1.
Peter