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

Application crash in libifcoremd.dll 13.1 on Windows Server 2008 R2, SP1

Lothar_Braun
Beginner
809 Views

Hi,

I am investigating a strange problem with just one of our customers on a Windows Server 2008 R2, SP1 machine.

This is an excerpt of the code:

       CHARACTER*80 ICBUFF
       INTEGER    MMBUFF
       PARAMETER (MMBUFF = 20)
       INTEGER    LFBUFF(MMBUFF)
       REAL       BFBUFF(MMBUFF)
       EQUIVALENCE (LFBUFF,BFBUFF)
       READ (ICBUFF,FMT='(BN,76X,I4)',ERR=9020)  LFBUFF(1)

Crash:

Unhandled exception at 0x05C70CCE (libifcoremd.dll) in crashdump.dmp:
0xC0000005: Access violation reading location 0x45C70F80.

Version of libifcoremd.dll:
13.1 - 101 (Update A)

I could not reproduce this crash on one of our machines and it happens with just one customer only and only with this library version (newer ones not tested).

Is there any known issue, a registry setting or perhaps a problem with permissions involved?

0 Kudos
1 Solution
Kevin_D_Intel
Employee
809 Views

Thank you. The address in the initial error appears to be a valid 32-bit address, ~1.1Gb. Perhaps that is within expected amount of memory range for the app to be working with.

This probably requires direct debugging to understand the root cause. Clearly something is very unique with the combination of the client’s system and your app. Another version of your product and older Intel library is not an equal comparison so that really does not offer much. The error reflects the app touching memory outside the allowable address space. That this occurred within the DLL does not directly reflect a defect with the DLL. The out-of-bound address the library accessed may have come from the app itself. That’s not meant to suggest there’s no possibility of defect in the DLL; however, it seems a defect in the DLL might show itself on other systems if that were the underlying cause.

You likely need to run a debug build of the app, maybe step through the code, with additional run-time checks enabled like /check:bounds and /traceback to get more details.

Another possibility might be to have them try a newer DLL although that may just put off the error, might avoid it even though something else might be getting unknowingly corrupted, or move it to a different location as that could change the memory footprint some. I can’t tell from the DLL’s version id exactly which older PSXE 2013 package it is from. It looks like it is within the PSXE 2013 Update 2 to Update 4 range. Older PSXE 2013 redist libraries are available from Redistributable libraries for Intel C++ and Visual Fortran Composer XE 2013 for Windows. Perhaps one could try only a newer version of the libifcore Intel DLL from a release newer than the version of PSXE 2013 used to build the app.

Finally, I don’t know whether the Doctor’s earlier article, Don't Touch Me There - What error 157 (Access Violation) is trying to tell you would offer other ideas/insight.

View solution in original post

0 Kudos
4 Replies
Kevin_D_Intel
Employee
809 Views

I’m unsure what is at play.

Is the app build IA-32 or Intel 64?

Are you saying it does not fail on your system with the same version of the library?

Have you tried setting Fortran > Run-Time > Generate Traceback Information to Yes and re-running to get some additional call stack details.

Does the code excerpt represent the point where you know the failure occurs?

0 Kudos
Lothar_Braun
Beginner
809 Views

Kevin D (Intel) wrote:

Is the app build IA-32 or Intel 64?

IA-32

Kevin D (Intel) wrote:

Are you saying it does not fail on your system with the same version of the library?

It works on many machines with different operating systems and this is the first report that it does not work. Another version of our product with an older library version works on that machine.

Kevin D (Intel) wrote:

Have you tried setting Fortran > Run-Time > Generate Traceback Information to Yes and re-running to get some additional call stack details.

Unfortunately - this is on a clients machine, but I got the following Stacktrace with CrashReport:

(libifcoremd.dll Dateiversion is 13.1.101.101)

 

>	libifcoremd.dll!05db0cce()	Unknown
 	[Frames below may be incorrect and/or missing, no symbols loaded for libifcoremd.dll]	
 	libifcoremd.dll!05d8adb4()	Unknown
 	ntdll.dll!7759f915()	Unknown
 	ntdll.dll!7759f8e1()	Unknown
 	libifcoremd.dll!05d2b955()	Unknown
 	libifcoremd.dll!05d48531()	Unknown
 	libifcoremd.dll!05d89167()	Unknown

Part of the disassembly:

05DB0C5C  sub         ecx,80h  
05DB0C62  movdqu      xmm0,xmmword ptr [esi-80h]  
05DB0C67  movdqu      xmm1,xmmword ptr [esi-70h]  
05DB0C6C  movdqu      xmm2,xmmword ptr [esi-60h]  
05DB0C71  movdqu      xmm3,xmmword ptr [esi-50h]  
05DB0C76  movdqu      xmm4,xmmword ptr [esi-40h]  
05DB0C7B  movdqu      xmm5,xmmword ptr [esi-30h]  
05DB0C80  movdqu      xmm6,xmmword ptr [esi-20h]  
05DB0C85  movdqu      xmm7,xmmword ptr [esi-10h]  
05DB0C8A  movntdq     xmmword ptr [edx-80h],xmm0  
05DB0C8F  movntdq     xmmword ptr [edx-70h],xmm1  
05DB0C94  movntdq     xmmword ptr [edx-60h],xmm2  
05DB0C99  movntdq     xmmword ptr [edx-50h],xmm3  
05DB0C9E  movntdq     xmmword ptr [edx-40h],xmm4  
05DB0CA3  movntdq     xmmword ptr [edx-30h],xmm5  
05DB0CA8  movntdq     xmmword ptr [edx-20h],xmm6  
05DB0CAD  movntdq     xmmword ptr [edx-10h],xmm7  
05DB0CB2  cmp         ecx,80h  
05DB0CB8  jge         05DB0C50  
05DB0CBA  mov         eax,ecx  
05DB0CBC  shr         eax,4  
05DB0CBF  shl         eax,4  
05DB0CC2  add         edx,eax  
05DB0CC4  add         esi,eax  
05DB0CC6  sub         ecx,eax  
05DB0CC8  shr         eax,4  
05DB0CCB  sfence  
05DB0CCE  jmp         dword ptr [eax*4+5DB0F90h]  <----- code pointer
05DB0CD5  cmp         ecx,80h  
05DB0CDB  jge         05DB0CE0  
05DB0CDD  jmp         05DB0D48  
05DB0CDF  nop  
05DB0CE0  sub         ecx,80h  
05DB0CE6  movdqa      xmm0,xmmword ptr [esi]  
05DB0CEA  movdqa      xmm1,xmmword ptr [esi+10h]  
05DB0CEF  movdqa      xmmword ptr [edx],xmm0  
05DB0CF3  movdqa      xmmword ptr [edx+10h],xmm1  
05DB0CF8  movdqa      xmm2,xmmword ptr [esi+20h]  
05DB0CFD  movdqa      xmm3,xmmword ptr [esi+30h]  
05DB0D02  movdqa      xmmword ptr [edx+20h],xmm2  
05DB0D07  movdqa      xmmword ptr [edx+30h],xmm3  
05DB0D0C  movdqa      xmm4,xmmword ptr [esi+40h]  

Thanks for looking into this.

0 Kudos
Kevin_D_Intel
Employee
810 Views

Thank you. The address in the initial error appears to be a valid 32-bit address, ~1.1Gb. Perhaps that is within expected amount of memory range for the app to be working with.

This probably requires direct debugging to understand the root cause. Clearly something is very unique with the combination of the client’s system and your app. Another version of your product and older Intel library is not an equal comparison so that really does not offer much. The error reflects the app touching memory outside the allowable address space. That this occurred within the DLL does not directly reflect a defect with the DLL. The out-of-bound address the library accessed may have come from the app itself. That’s not meant to suggest there’s no possibility of defect in the DLL; however, it seems a defect in the DLL might show itself on other systems if that were the underlying cause.

You likely need to run a debug build of the app, maybe step through the code, with additional run-time checks enabled like /check:bounds and /traceback to get more details.

Another possibility might be to have them try a newer DLL although that may just put off the error, might avoid it even though something else might be getting unknowingly corrupted, or move it to a different location as that could change the memory footprint some. I can’t tell from the DLL’s version id exactly which older PSXE 2013 package it is from. It looks like it is within the PSXE 2013 Update 2 to Update 4 range. Older PSXE 2013 redist libraries are available from Redistributable libraries for Intel C++ and Visual Fortran Composer XE 2013 for Windows. Perhaps one could try only a newer version of the libifcore Intel DLL from a release newer than the version of PSXE 2013 used to build the app.

Finally, I don’t know whether the Doctor’s earlier article, Don't Touch Me There - What error 157 (Access Violation) is trying to tell you would offer other ideas/insight.

0 Kudos
Lothar_Braun
Beginner
809 Views

Update:

I could not find the cause, but I suspect some interference with some other software. Our customer is now testing other options, so we won't invest any more time in that. Hopefully, no one else will have that problem.

Thanks for your suggestions.

Lothar

 

0 Kudos
Reply