Could you specify which problems arenew with 034, which ones are existing?

Vasci,

Let me preface this by stating I don't work for Intel nor MS. I currently use VS 2005 and IVF 9.1.032. Some time back (18 months) I was using VS 2003 and IVF 8.n.mm.

At that time, I too was experiencing build problems where build would intermittantly crash. Usually a fatal error from Devenv reading or writing incorrect addresses. This happened with Build->Debug. I had a 50/50 chance of crash. The finger pointing between Intel and MS went back and forth for several months and over several updates. Then for some reason I installed VS on a different system, copied my application files over *** but did not copy the solution and project files. Instead I re-entered the solution and project files by hand (~10 projects, ~750 files). No problems with Devenv. I then deleted the solution and project files on the main development system, (re-booted to flush the deletes), then re-created the solution and project files. And "ta da" no problems with Devenv. What this means... I haven't a clue. But I haven't had problems since.

I've seen the 0 length file thing before. From my recollection the file is open in multiple places at once (causing write protect) but where one of the opens is a Create file (which forces the file write pointer to byte 0). The create succeeds (making file 0 bytes) but writes are inhibited. I cannot say for sure, but I think the problem had to do with having the project open in multiple different solutions at the same time.

These were old problems. But perhaps the problems between then and now are related.

Hope this helps

Jim Dempsey

Hi Jim,

You have IVF 9.1.xxx, do you mean ICL 9.1.xxx? There was a build problem with icl, but it should have been fixed.

Jennifer

No, I have Intel Visual Fortran. The problem I used to have (over a year ago) was a problem with Devenv crashing. The description of the original post sounded very similar. Although I no longer have the problem, this is not conclusive that the problem was eliminated. Some times problems (symptoms) go away without a fix.

In my case, the problem occurred running debug sessions.

loop
In IDE making edits
F5 to compile and run
Debug
Stop to IDE
end loop

I used to have a 50/50 chance a Devenv crash would occurs after F5.
Strangely, sometimes the Devenv crash would be immediately and other times maybe 30 seconds or moreinto the debug session. "We're sorry but your application... (devenv) and will have to be closed".

That was really annoying. Like I said, I haven't had that problem for a year now.

At first thought you might think the thread's poster's problem would not be similar to the problem I used to have. After all he is compiling from a batch file. However, also note that his compilations are being made by way of the batch file calling devenv to perform the compilation. In my case, the IDE (running in Devenv) called devenv (recursive) to perform the compilation. As explained before, in my opinion, this is related to the null file situation where on application has a file open for exclusive write (but permits) another application to create new file of same name, then inhibit write. This, again in my opinion, was a sequencing problem between the dependency checking process in devenv and the compilation process attempting to create the file on which the dependency check was being made. i.e. there was a race condition amongst:

devenv file dependency check
compiler producing file of dependency check
operating system performing lazy write(close) or other?

Just a suspicion.

Jim

Jim,

The problem you describe had to do with the Fortran Debug Expression Evaluator and an issue relating to when DLLs get loaded and unloaded. It is unrelated to the build problem described here and that problem was fixed.

Vasci,

Could you report each of your problems to https://premier.intel.comso we can track/fix each problem? It's ok if you couldn't provide the testcase. But if you can give more detail steps, we could try to duplicate the problem.

Thanks,

Jennifer

Vasci,

As a diagnostic exercise, see what happens when you burn your project file to CD-ROM then build using the immutable project files. Apparently write protected is not sufficent.

The intent here is not necessarily to give you a work-around but to force some sort of error, hopefully with a finger pointing back at the offending code.

On this topic, I cannot understand why a vendor's product would purposely go out of it's way to modify a user file that is explicitly set to Read Only without asking for permission.

Jim Dempsey

Visual Studio could be the culprit as well or in addition to the Intel integration tool.

My guess as to why the tool is unset ting the R/O flag is because when you install from the CD-ROM (or DVD) that if "demo" applications arecopy to your system that the resulting project files would be R/O. Intel, or more likely Microsoft may have received a lot of complaints that the demos wouldn't run (due to being R/O). Their "fix" was to rename the project files to same name but with R/W attributes. In my opinion, this was a "crock" fix. The correct way to handle this is for the Installer to change the R/O to R/W on the files that need to be changed. VS (and integration tools) should be able to handle R/O files, including project and solution files. And if VS requires some R/W capabilities, it should do so by way of an intermediary file (not necessarily in the project directory, which may be on R/O media).

Jim Dempsey

Jim,

There's a fix for changing the .icproj's read-only attribute when doing the batch build with "devenv". This fix should be in the next 9.1 update.

Using the CD is a great idea for testing. THANKS!

Jennifer

Jennifer,

The behavior we want is

If the .icproj is R/Okeep it R/O

Do not rename to R/W

Do not rename to R/W, modify, rename back to R/O

Do not provide an option switch change from R/O to R/W

If the user needs R/W on the project then they must make an extra, and explicit, action to convert from R/O to R/W.

A userhas to takeexplicit action to make the file R/O. If they went through this extra effort to make the file R/O, then it is only appropriate for the tools to abide by the wishes.

Think of this asthe door lock on the stall in the bathroom. Do you want the lock to work or do you want it to automatically unlatch anytime someone pulls on the door?

Jim Dempsey

Hello all,

Thanks for your ideas and suggestions. I've sent those to the development team.

I've got notified that the bug that modifies .icproj when doing batch-build is already fixed in the 9.1.034.I tried with 034 on varies projects (console, atl dll, with special intelc options, with post-build event), and used VSS as well, didn't see the "overwritting the .icproj file attribute" issue when opening the property/rebuild the solution.

So please try the 9.1.034, if it still exist, please let us know. It may not be possible to send us all your source code, but if you can provide the .icproj and the relevent .vcproj, it should help us a lot on fixing the problem more quickly.

Thanks again,

Jennifer

vasci_intel ,

>> The IDE integration should never , ever, overwrite a R/O .icproj.

Do you have the issue number so I can follow up on? Maybe we just missed an important step.

Thanks,

Jennifer

Jennifer,

>> It may not be possible to send us all your source code, but if you can provide the .icproj and the relevant .vcproj, it should help us a lot on fixing the problem more quickly.

Please do not take this personally...

In regards to this issue (unauthorized renaming project to R/W), your comments is indicative of your failure to recognize the root cause of the problem. And apparently thus the reason why sending you a project will fail to expose the problem.

Consider this:

Someone sends you a R/O project file (and source files). Next, in the process of downloading orof you copying these files from the download directory to a test directory, the files become R/W. You run your tests... No problem exposed.

For this problem, you firstmust understand the problem (without example) as described. Then it becomes a simple matter for you to conceive of a test case such as:

Make a "Hello world" project. Exit the IDE, Rename theicproj and the relevant .vcproj files with same name but with R/O attributes. Copy these files to a separate folder for reference. Then run the IDE (and/or batch build)and see what happens.

a) Are any ofthe icproj and the relevant .vcproj files now R/W? If so why?

b) If not, does WinDiff show any changes

If the answer is No to both a) and b) then problem fixed.

Exception case:

If during your test compile (either from IDE or batch/command line) something aborts due to R/O on icproj and the relevant .vcproj files, then you must recognize that the fix is:

Change the code to be able to use R/O files. (preferred)
Notify the user which icproj and the relevant .vcproj files need to be R/W

The fix is NOT

Use code to change the files to R/W

Why, might you ask. Because the person in charge of source control needs to know if there is any potential for change in "Frozen" source code including icproj and the relevant .vcproj files. It is not appropriate for Intel, Microsoft, or other vendor to usurp this control function.

Jim

Thanks so much for the steps Andrew.

I never tried to change the .vcproj. So this is surely a new case. .icproj shouldn't be changed if the .vcproj has changed because the "/sharevcproj" is set by default. So multiple projects/groups can share theproject that hasbeen converted to IntelC.

I've justduplicated the problem with your steps. will create a tracker to the dev-team shortly.

will post the progress here soon.

Thanks again for all your patience.

Jennifer