Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

32-bit compiler

Robert_C_2
Beginner
2,847 Views

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.

0 Kudos
39 Replies
Robert_C_2
Beginner
1,334 Views

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.

0 Kudos
Robert_C_2
Beginner
1,334 Views

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)?

0 Kudos
Steven_L_Intel1
Employee
1,334 Views

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.

0 Kudos
Bernard
Valued Contributor I
1,334 Views

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>>>

0 Kudos
Bernard
Valued Contributor I
1,334 Views

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.

0 Kudos
John_Campbell
New Contributor II
1,334 Views

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

0 Kudos
Bernard
Valued Contributor I
1,334 Views

>>>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?

0 Kudos
Steven_L_Intel1
Employee
1,334 Views

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?

0 Kudos
Bernard
Valued Contributor I
1,334 Views

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.

0 Kudos
Robert_C_2
Beginner
1,334 Views

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.

0 Kudos
Robert_C_2
Beginner
1,334 Views

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.

 

0 Kudos
Steven_L_Intel1
Employee
1,334 Views

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.

0 Kudos
TimP
Honored Contributor III
1,334 Views

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.

0 Kudos
Steven_L_Intel1
Employee
1,334 Views

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.

0 Kudos
Bernard
Valued Contributor I
1,334 Views

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/

0 Kudos
Steven_L_Intel1
Employee
1,334 Views

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.

0 Kudos
Robert_C_2
Beginner
1,334 Views

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?

0 Kudos
Steven_L_Intel1
Employee
1,334 Views

I am dubious the compiler update is significant.

0 Kudos
Bernard
Valued Contributor I
1,334 Views

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.

0 Kudos
Reply