My application uses the Intel IPP version 5.3.1. We recently made a move to have our application be compatible with 64 bit operating systems, and we've had three crashes recently in the exact same spot:
Unhandled exception at 0x070c460e (DxCam.dll) in Werks_2.5.956_2008-11-11_215733.dmp: 0xC000001D: Illegal Instruction.
DxCam.dll!_p8_ownpiDecimateYUY2super() + 0x2a bytes
DxCam.dll!_p8_ippiResizeYUV422_8u_C2R@68() + 0x33d bytes
DxCam.dll!CWMVManip::ScaleAndCompressImage(unsigned char * pMediaType=0x08ef7480, unsigned char * pImageData=0x0bbc0020, unsigned char * * pJPEGThumbnail=0x0f18f7d4, unsigned long * JPEGThumbnailSize=0x0f18f7c8) Line 820 + 0x66 bytes C++
I don't have source code, of course, but here's the disassembly:
059845E4 push ebp
059845E5 mov ebp,esp
059845E7 and esp,0FFFFFFF8h
059845EA push edi
059845EB push esi
059845EC push ebx
059845ED sub esp,6Ch
059845F0 mov ebx,dword ptr [ebp+8]
059845F3 mov esi,dword ptr [ebp+18h]
059845F6 movsd xmm4,mmword ptr [ebp+24h]
059845FB movsd xmm6,mmword ptr [ebp+2Ch]
05984600 cvttsd2si eax,xmm4
05984604 cvtsi2sd xmm0,eax
05984608 movaps xmm1,xmm4
0598460B movaps xmm3,xmm6
0598460E db 66h
And here are the register values:
EAX = 00000002 EBX = 16331F10 ECX = 000000A3 EDX = 00000040 ESI = 000000A3 EDI = FFFFFF64 EIP = 0598460E ESP = 0B98F400 EBP = 0B98F478 EFL = 00010206
Here's the DxDiag info for one of the machines:
...I have a feeling that all of these machines are using the E5200, although I'm not sure of that yet. Does anyone have any idea what may be causing this crash, or how I can further isolate the underlying cause? It probably has something to do with running on a 64 bit OS (we are still a 32 bit OS, running under WOW64), but I'm not sure.
Any advice is much appreciated.
I understand that it contains SSE4.1 instructions, but why would the IPP dispatch to code that contains 4.1 instructions when the processor clearly only supports up to SSE3? (I verified this in CPU-Z, and also in Intel's documentation)
We're using static linking? Is that what you're asking about with respect to dispatching? We've always assumed that the IPP handles all dispatching under the hood, so we've never dealt with that in our application. This is the first time I've had an issue with crashing in the IPP, and this application runs on thousands of different computers, so...seems like something is different with the E5200, IMO.
A bit more info--we're using Static Linking (with dispatching), so the IPP handles all of the dispatching under the hood. I believe this is a dispatching error in 5.3.1 for the E5200 processor, and I now believe that 64-bit doesn't factor into the problem. I'm in the process of verifying this.
I'm also going to try updating to 5.3.4 to see if it resolves any issues with dispatching.
I reproduced the problem on 32-bit Vista, so it definitely has nothing to do with 32/64 bit operating system. I think there's a bug in the 5.3.1 dispatcher that causes it to dispatch the wrong code for the E5200 processor, which ultimately causes my application to crash.
Do you know if this bug has been fixed in more recent versions of the IPP? And if so, what is the most recent version? I'd like to avoid doing a major version update to 6.0, if possible, since I'm trying to work around a tight release schedule and don't want to make any major changes.
I'll give it a try.
To reproduce the problem, we ordered one of these:
...which is the same system our customers encountered the problem on. I suspect you can reproduce it on any E5200-based system, however. I do have a small test app I've been writing that I can lend you, although I have not yet tested whether or not it will reproduce the issue.
I included a small test application (just source code) that I believe will reproduce the issue. I change it to use dynamic linking so I could test a bunch of different versions of the IPP. I do not yet know if this app will reproduce the problem on the E5200, but I'll let you know as soon as we have an opportunity to test it.
I'll see about getting remote desktop setup on the HP box we purchased so we can do further testing.
Thank you for your help; I look forward to a resolution.
Hmm. Not sure if my attachment made it. In any event, I believe this chunk of code should reproduce the problem, so long as you're running it on an E5200 and the IPP 5.3.1:
[cpp]// Let's test our resize function We'll do this with some dummy images
// hard coded to VGA. We downscale using supersampling to QVGA.
unsigned char* pImageData = new unsigned char[640 * 480 * 2];
unsigned char* pScaledData = new unsigned char[320 * 240 * 2];
IppiSize sourceSize, destSize;
sourceSize.width = 640;
sourceSize.height = 480;
destSize.width = 320;
destSize.height = 240;
sourceRect.x = 0;
sourceRect.y = 0;
sourceRect.width = 640;
sourceRect.height = 480;
IppStatus retVal = ippiResizeYUV422_8u_C2R(pImageData, sourceSize, 1280, sourceRect, pScaledData,640,destSize,0.5,0.5,8);
printf("Resize YUV422 result: %srn", ippGetStatusString( retVal ));[/cpp]
Again, I have not had a chance to see if this code reproduces the problem on the E5200/5.3.1 (Thanksgiving--everyone's out of the office, including the person I need to do the testing), but I suspect it will. I get a valid return result on my laptop (Core 2 Duo), so I think the function call is working correctly in the test application.
OK, I isolated this problem as a bug in IPP 5.3.1; when using the IPP to perform dispatching, 5.3.1 will dispatch the e5200 as a processor with sse 4.1 support. I updated to 5.3.4, and it correctly dispatches it as a processor with SSE3 support. I also recreated the issue in a simple application I wrote where I could link against 5.3.1, 5.3.4 and 6.0; it is trivial to reproduce.
After upgrading my application to use 5.3.4, I no longer experience a crash.
The sample application you gave me looks like it works fine, but I also see that it was using static linking against IPP 5.3.4, so that's to be expected.
One concern I now have, however, is the reliability of the IPP dispatching routines.