topic "Unhandled exception" - the project had gone crazy in Intel® Fortran Compiler

"Unhandled exception" - the project had gone crazy

denara — Fri, 09 Sep 2011 16:12:12 GMT

Hi,

Yesterday I was working on a fortran file of my Fortran/C++ project. Adjusting and debuging an input data routine. The project was working fine. (VS2005 + IVF 11.1.070 on Windows 7)

But today the project has gone crazy. Every time I attempt to run it (debug mode) I get a "Unhandled exception" but not always the same message.

Once I get:

"Unhandled exception at 0x13cbe6d0 in NH2_v90graf.exe: 0xC0000005: Access violation reading location 0x13cbe6d0."

The program stops at a "break". I stop debugging and star over. The I get another message:

"Unhandled exception at 0x140be6d0 in NH2_v90graf.exe: 0xC0000005: Access violation reading location 0x140be6d0."

I repeat the process: stop debuggind, begin again. And once more a diferent message:

"Unhandled exception at 0x13e3e6d0 in NH2_v90graf.exe: 0xC0000005: Access violation reading location 0x13e3e6d0."

The program seems to break at point that no relation to the routine I was working on.
Between each run I rebuild the entire project. Ive been doing this for more than 3 hours by now. Ive had many unhandled exceptions and one or two successful runs.

I havent change anything in the project. I began wher I stopped yesterday.
The only diference is that when I turned the compluter off yesterday, Windows has made an update. I thought this might be the cause and restored the system. But, still not working.

I have no idea of what may be happening. Any guess?

Thanks
Andrea

"Unhandled exception" - the project had gone crazy

Steven_L_Intel1 — Fri, 09 Sep 2011 16:37:46 GMT

The locations for the access changes because Windows 7 does Address Space Layout Randomization. Every time you run the program, memory allocations are a bit different. The location in your program is the same. If you Break in the debugger, it should show you what was executing at the time - it may be a library routine called from your code, in which case you would use the Call Stack drop down list in Visual Studio to see where things were called from.

"Unhandled exception" - the project had gone crazy

denara — Fri, 09 Sep 2011 18:27:43 GMT

Hi Steve

I started debugging from the begining, as you suggested.

The problem seems to occur in a set of 3 initialization routines in the begining of the fortran code.

So I decided to run breaking at each line (or at internediate parts of the routines).

I passed de 1st one and the program aborted in some point in the 2nd.

So I started all over. This time I did not go in to the 1st routine, as it has passed before. I stepped it over, but for my surprise the program aborted before reaching the 2nd. routine.

It passed when breaking at each line, but aborted when stepping it over.

There are a lot of variables and vectors being initialized. To initialize the vectors I'm using something like A=0 instead of an explicit do loop. Would it be a problem?

"Unhandled exception" - the project had gone crazy

Steven_L_Intel1 — Fri, 09 Sep 2011 18:41:35 GMT

Not necessarily, but I see that the address it shows is quite large. Can you reduce this down to a small test case I can look at? You may want to try setting Optimization > Heap Arrays to 0, rebuild, and see what happens.

"Unhandled exception" - the project had gone crazy

denara — Fri, 09 Sep 2011 19:00:09 GMT

The project is a commecial application with almost a thousand files and hundred thousand lines. I cant reduce it.
The optimization option was not successful
I am double checking the initialization routines.
What I cant figure out is why as it working yesterday and not today?...

"Unhandled exception" - the project had gone crazy

Steven_L_Intel1 — Fri, 09 Sep 2011 19:41:14 GMT

You may have run out of virtual memory, depending on your system's pagefile usage. Try rebooting and running the program again.

"Unhandled exception" - the project had gone crazy

jimdempseyatthecove — Sat, 10 Sep 2011 01:19:14 GMT

Andrea,

RE: page file

The Windows System log may contain a useful error message (e.g. not enough free disk space to expand your page file). Is your Windows 7 x64? If so, add a configuration to build as x64 (your error messages are indicating x32 build).

Note, Windows often defaults to fixed page file size (this size may have changed during your last updata). You can alter the properties to permit it to expand until much larger.

Jim Dempsey

"Unhandled exception" - the project had gone crazy

denara — Mon, 12 Sep 2011 18:27:27 GMT

Steve and Jim,

Thanks for your suggestions, but I think the problem is not related to the project itself.

I restored an old distributed version from SVN and built the project, which, by the way, was working nicely. I could run the debug successfully once. But it crashed in the second try. And after that, no matter what I do, it crashes. It sometimes works when I reboot the computer. but just for one or two times.

May be there is some problem with the last Windows updates, since things were working fine before it.
The computer is rather new, so very few things on HD. It has RAM 4GB, Windows 7 32 bits, Intel Core 2 Quad. Better than my old one. So I dont belive it is a system requirement problem.

I will try to restore the system, and if does not work, reinstall Windows. Let's see.

Thanks again.
Andrea

"Unhandled exception" - the project had gone crazy

Steven_L_Intel1 — Mon, 12 Sep 2011 19:37:50 GMT

It is beginning to sound as if it's a problem wth the PC, but again I wonder if something is taking up virtual memory that your application needs. As the computer is "rather new", I am somewhat surprised that you are running the 32-bit version of Windows 7. You really should use the 64-bit version if you can, and I predict that if you do, and build the project in an "x64" configuration, the problems will go away.

"Unhandled exception" - the project had gone crazy

denara — Tue, 13 Sep 2011 13:05:24 GMT

The PC is not mine. It's from the company I work for, and unfortunately I cannot choose the OS. If so, I could try the 64-bit.

But now I may have found the solution.

As I mentioned, the problem started after a Windows Update (KB2607712). I tried to restore the system, but didnt work out.

I reinstalled the Microsoft Visual C++ 2005 Redistributale (vcredist_x86.exe) and things were back to normal.

Then I let Windows made the update KB2607712, and the program crashed again.

So I reintalled vcredist. Back to normal.

My conclusion: something on windows update has messed up my VS2005 so that vcredist has to be installed AFTER the update.

Dont know if it will happen again, with some future update. But by now, at least Im working.

Andrea