32-bit compiler

32-bit compiler

Has anyone had a problem using the 32-bit Fortran compiler after returning from sleep or hibernation mode?  I get an internal compiler error C0000005.

40 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Not me - I use the hibernation and sleep mode all the time on a laptop and never had such a problem.

In all the years I have used the compiler after hibernate or sleep, I've never seen this happen. Is it consistent for you? On any source? If you compile again do you still get the error? I assume the same source compiled ok at some point...

Steve - Intel Developer Support

Are your compilations taking so long you go into sleep and/or hibernation mode?

Jim Dempsey

www.quickthreadprogramming.com

Quote:

Steve Lionel (Intel) wrote:

In all the years I have used the compiler after hibernate or sleep, I've never seen this happen. Is it consistent for you? On any source? If you compile again do you still get the error? I assume the same source compiled ok at some point...

Please note that this is only occurring with the 32-bit compiler, not the 64-bit.  I have no doubt it is system dependent.  It happens on my desktop, but not on my laptop.

Once the computer returns from sleep, the same source that previously compiled properly will not compile.  I get an internal compiler error.  This is true regardless of the source. No matter how many times I attempt to recompile, I get the same error.  The only thing I can do to get the compiler to work again is to restart the computer.

I have heard that an environment variable or a path can be lost after sleep or hibernation.  I assume that something like that is occurring.

Quote:

jimdempseyatthecove wrote:

Are your compilations taking so long you go into sleep and/or hibernation mode?

Jim Dempsey

No, the compilations take less than a minute.  I want to take advantage of the power saving provided by sleep/hibernation when the computer is not in use, but I don't want to shut down and wait for the computer to reboot.

If an environment variable change could cause an internal compiler error, that would be a compiler bug. I'd suggest uninstalling and reinstalling the compiler - get the latest one available - and see if the problem persists.

Steve - Intel Developer Support

Quote:

Steve Lionel (Intel) wrote:

If an environment variable change could cause an internal compiler error, that would be a compiler bug. I'd suggest uninstalling and reinstalling the compiler - get the latest one available - and see if the problem persists.

I have tested the latest version of the Fortran compiler (and the new Beta version).  The problem persists.

I've never experienced our symptoms on any of my notebooks over the last 10 years.

Is there anything else we need to know about your setup?

Is the compiler, and licenses server if applicable, located on the notebook? (as opposed to through network or external storage)
Is the compiler running inside a Virtual PC?
other...?

What is your build environment (Visual Studio, the "light" Visual Studio, Eclipse, other, command line)?
If VS, what happens if you have a second instance running a solution for a C++ project (does that error out too)?

Jim Dempsey

www.quickthreadprogramming.com

Quote:

jimdempseyatthecove wrote:

I've never experienced our symptoms on any of my notebooks over the last 10 years.

Is there anything else we need to know about your setup?

Is the compiler, and licenses server if applicable, located on the notebook? (as opposed to through network or external storage)

Is the compiler running inside a Virtual PC?

other...?

What is your build environment (Visual Studio, the "light" Visual Studio, Eclipse, other, command line)?

If VS, what happens if you have a second instance running a solution for a C++ project (does that error out too)?

Jim Dempsey

Please note that the problem is on a desktop, not a notebook.

The compiler and license is located on the desktop.

The compiler is not running inside a virtual PC.

There is nothing else unusual about my setup.

I build the executable on the command line.

I have only the Fortran compiler, and I don't use C++.

 

What happens if on resume, you close any CMD window, then open a new IVF command line window?

Error or no error?

Usually when you receive a C00000005 error you have a from ... location. What is the location?

Also, is there any other text shown in the CMD window?

Jim Dempsey

www.quickthreadprogramming.com

If this is happening at the command line and you suspect environmental variables, why don't you compare the output of the DOS SET command before and after the problem occurs and see if there are any notable differences?

Quote:

jimdempseyatthecove wrote:

What happens if on resume, you close any CMD window, then open a new IVF command line window?

Error or no error?

Usually when you receive a C00000005 error you have a from ... location. What is the location?

Also, is there any other text shown in the CMD window?

Jim Dempsey

Closing the old command window and opening a new command window makes no difference.

There is no location specified.

The only other text refers to "code 1".

Quote:

Repeat Offender wrote:

 

If this is happening at the command line and you suspect environmental variables, why don't you compare the output of the DOS SET command before and after the problem occurs and see if there are any notable differences?

I did what you said, and there are absolutely no differences in the output of the SET command before and after sleep/hibernation. Yet the problem still occurs.

Are there any similar commands I can use to check if there are any differences in my system?

Try temporarily disabling your antivirus/antimalware program (assuming you have one), then see if you can reproduce the problem.

Steve - Intel Developer Support

Quote:

Steve Lionel (Intel) wrote:

Try temporarily disabling your antivirus/antimalware program (assuming you have one), then see if you can reproduce the problem.

I only have the software that comes with Windows.  I tried disabling Windows Firewall, but it doesn't make any difference.

Is it a hardware error - a memory fault, for example, so that when windows is reloaded after the hibernation, something has been corrupted, could be in the compiler, or any of the DLL's reloaded into memory.

It woudl be interesting to know whether the error persisted upon exchanging the memory sticks with another set, or even swapping the pair of sticks around (assuming there are two).

David

There's really no good way to know what the problem is unless it can be generally reproduced. I've never heard of a problem of this nature before and can't imagine what, other than a problem with the particular system, that would cause such behavior.  If restarting the computer is the only thing that solves it, and you tried the latest compiler, my guess is that Windows is failing to resume correctly and has loaded something incorrectly into memory that the compiler uses.

Steve - Intel Developer Support

After resume, then after error (try compile and produce error message)

Snapshot the dialog box (with it in focus, press Alt-PrtScr, then paste into Paint, and save .jpg), and post it here.

Then run MS Event Viewer, expand Windows Logs, see if anything in any of the logs can be associated with the compilation.

Jim Dempsey

www.quickthreadprogramming.com

This is access violation error and if Win exception handling mechanism was able to catch that exception you should see a description in Event viewer which could give some information at least the name of the faulting module.I suppose that upon resuming from the sleep state some module (dll?) is mapped back and somehow causes 0xc0000005 error.

 

 

Quote:

jimdempseyatthecove wrote:

After resume, then after error (try compile and produce error message)

Snapshot the dialog box (with it in focus, press Alt-PrtScr, then paste into Paint, and save .jpg), and post it here.

Then run MS Event Viewer, expand Windows Logs, see if anything in any of the logs can be associated with the compilation.

Jim Dempsey

I have attached the 32-bit compiler error message after resume.  For comparison, I have attached the successful 64-bit compile of the same source after resume.

I found nothing in the logs of the Event viewer that seems associated with the compilation.

Attachments: 

AttachmentSize
Downloadimage/jpeg compile32bit_1.jpg82.29 KB
Downloadimage/jpeg compile64bit_1.jpg88.49 KB

Quote:

iliyapolak wrote:

This is access violation error and if Win exception handling mechanism was able to catch that exception you should see a description in Event viewer which could give some information at least the name of the faulting module.I suppose that upon resuming from the sleep state some module (dll?) is mapped back and somehow causes 0xc0000005 error.

 

 

I could find nothing in the event viewer that seems associated with the compilation.

Since the problem is obviously system dependent, is there anyone with a Dell XPS 8500 desktop who can try the 32-bit Fortran compiler after waking from sleep/hibernation to see if it works for them (please note the problem occurs only with the 32-bit compiler, not the 64-bit compiler)?

I don't expect the event log to show anything since the exception was handled by the compiler (and turned into an ICE.) There isn't any plausible way of diagnosing this other than running the compiler under the debugger (which you can't do) and see where it fails. That restarting the computer makes the problem go away tells me it's a system failure, not a compiler bug.

Steve - Intel Developer Support

I had similar issue with the ICC av exception and attached debugger was not able to break on access violation exception , but it break on CLR exceptions probably thrown by VS.

>>>There isn't any plausible way of diagnosing this other than running the compiler under the debugger (which you can't do) and see where it fails>>>

Quote:

Robert C. wrote:

Quote:

iliyapolak wrote:

This is access violation error and if Win exception handling mechanism was able to catch that exception you should see a description in Event viewer which could give some information at least the name of the faulting module.I suppose that upon resuming from the sleep state some module (dll?) is mapped back and somehow causes 0xc0000005 error.

 

 

 

I could find nothing in the event viewer that seems associated with the compilation.

So probably it was handled by the compiler itself.

Have you run chkdsk on the c: drive lately? It could be a problem with the hiberfil.sys being corrupted.I once had a problem with disk errors being reported as program errors.

John

>>>I don't expect the event log to show anything since the exception was handled by the compiler (and turned into an ICE.) >>>

Steve do you mean ICE breakpoint?

There are two basic ways the compiler can report ICE. One is that there is an explicit test for a case that should never happen, and an "abort" routine is called that puts out the ICE message and exits. The other, which happened here, is that an access violation occurred and the compiler's exception handler caught it, issued the message and exited.

If one could run the compiler under a debugger and tell the debugger to break on any exception, one could see where in the compilation the error occurred. Because this problem seems specific to Robert's system, it isn't something we can do here (where we have access to the compiler sources, etc.) That it happens with both the 14 and 15 compilers and goes away after a reboot tells me that it isn't a compiler bug but rather Windows, or perhaps one of the device drivers, is failing to restore properly after sleep/hibernate, and is corrupting memory.

Robert, when did this problem start occurring? What change to your system was made just before then?

Steve - Intel Developer Support

When I had compiler crash and debugger did not catch av exception I suspected built-in compiler exception handler being responsible for handling this erroneous situation.

>>>If one could run the compiler under a debugger and tell the debugger to break on any exception, one could see where in the compilation >>>

As a side note I did it , but instead of compiler VS debugger was debugged under windbg.

Quote:

John Campbell wrote:

Have you run chkdsk on the c: drive lately? It could be a problem with the hiberfil.sys being corrupted.I once had a problem with disk errors being reported as program errors.

John

I tried chkdsk, but the dialog box disappeared as soon as it finished running.  However, I did not see anything that looked suspicious in the dialog box while it was running.

Quote:

Steve Lionel (Intel) wrote:

There are two basic ways the compiler can report ICE. One is that there is an explicit test for a case that should never happen, and an "abort" routine is called that puts out the ICE message and exits. The other, which happened here, is that an access violation occurred and the compiler's exception handler caught it, issued the message and exited.

If one could run the compiler under a debugger and tell the debugger to break on any exception, one could see where in the compilation the error occurred. Because this problem seems specific to Robert's system, it isn't something we can do here (where we have access to the compiler sources, etc.) That it happens with both the 14 and 15 compilers and goes away after a reboot tells me that it isn't a compiler bug but rather Windows, or perhaps one of the device drivers, is failing to restore properly after sleep/hibernate, and is corrupting memory.

Robert, when did this problem start occurring? What change to your system was made just before then?

I only recently discovered the 32-bit compiler problem (I normally use the 64-bit compiler).  There were no changes to my system that I know of just before discovery.  

I discovered the 32-bit compiler problem while pursuing a similar problem regarding the GEMM Blas MKL routine hanging up after resuming from sleep/hibernation (see MKL Forum topic GEMM Blas routine).   This problem has existed since I purchased my computer two years ago.  

No one else can reproduce the GEMM Blas problem either.  The issue was previously submitted to Intel Premier Support without resolution.  I thought if I could resolve the 32-bit compiler problem, I might have a clue to the GEMM Blas problem.

 

Seriously, I think that at a minimum you need to have Windows reinstalled on this system. Something is seriously wrong with it and you're just wasting time trying to attack it from the wrong end.

Steve - Intel Developer Support

If you run a disk repair and your Windows no longer boots (if that's your concern), it may be possible to recover from a restore point, run disk repair again, and then see normal behavior.

I spoke with Robert on the phone. All indications are that it's a hardware problem (possibly memory), but it's not worth the hassle to him to track it down further. (His PC is personally owned and out of warranty.) I had suggested swapping memory in and out, but he didn't want to get into that.

Steve - Intel Developer Support

Seems like hardware(memory) issue. Maybe memtest could reveal some faulty memory cells when scheduled to run right after pc resuming from the sleep.

http://www.memtest.org/

I don't think memtest would be of much help because you have to boot into it, and the act of doing so will hide the problem Robert is encountering. It certainly can't hurt to run it, though, just to test the memory.

Steve - Intel Developer Support

One other thing I will mention regarding the related GEMM Blas MKL problem (see MKL forum topic GEMM Blas routine). The GEMM Blas routine also does not work after resuming from sleep.  It hangs up in an endless loop and never finishes.  I found that the problem is case dependent, i.e., DGEMM (the double precision version) works, but CGEMM and ZGEMM (the complex number versions) do not.  Originally SGEMM (the single precision version) did not work, but a recent compiler update caused it to start working properly.  The change occurred between versions 198 and 202 of the Fortran compiler.  No other update since then has had any effect (including the beta version).

Is the status of the problem being affected by a compiler update of any significance?

I am dubious the compiler update is significant.

Steve - Intel Developer Support

Quote:

Steve Lionel (Intel) wrote:

I don't think memtest would be of much help because you have to boot into it, and the act of doing so will hide the problem Robert is encountering. It certainly can't hurt to run it, though, just to test the memory.

Yes true.I did not take into account the need to boot into it.

Windows Memory Diagnostic Tool should be run after resuming from the sleep.

Leave a Comment

Please sign in to add a comment. Not a member? Join today