Re: Crash when calling ippiResizeYUV422_8u_C2R

jnoring · ‎11-24-2008

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:

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

11/11/2008, 14:13:35
JOHN-PC
Windows Vista Home Premium (6.0, Build 6001) Service Pack 1 (6001.vistasp1_gdr.080917-1612)
English (Regional Setting: English)
HP-Pavilion
FK785AA-ABA s3620f
Phoenix - AwardBIOS v6.00PG
Pentium Dual-Core CPU E5200 @ 2.50GHz (2 CPUs), ~2.5GHz
3964MB RAM
1662MB used, 6442MB available
C:\Windows
DirectX 10
Not found
6.00.6001.18000
1
0

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

Vladimir_Dudnik · ‎11-25-2008

Hello,

IPPlibraries with P8 prefixcontainSSE4.1 instructionsand can't be run on E5200 processor as it only support SSE3 instruction set. How did you do dispatching of IPP libraries in your application?

Regards,
Vladimir

jnoring · ‎11-25-2008

Quoting - vdudnik

Hello,

IPPlibraries with P8 prefixcontainSSE4.1 instructionsand can't be run on E5200 processor as it only support SSE3 instruction set. How did you do dispatching of IPP libraries in your application?

Regards,
Vladimir

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.

jnoring · ‎11-26-2008

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.

jnoring · ‎11-26-2008

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.

Vladimir_Dudnik · ‎11-27-2008

We are investigating this issue. Please stay tuned

Vladimir

Vladimir_Dudnik · ‎11-27-2008

We need some way to reproduce your issue. Is it possible to provide actual parameters used when you get a crash in this function? Or may be you have simple test case which reproduce the crash?

Vladimir

Vladimir_Dudnik · ‎11-27-2008

Could you please try to run executable from attached archive (note it is password protected, password is 123). This is prebuilt IPP custom DLL sample, it is useful as it prints version of IPP loaded by dispatcher including cpu specific prefix

Vladimir

jnoring · ‎11-27-2008

Quoting - vdudnik

Could you please try to run executable from attached archive (note it is password protected, password is 123). This is prebuilt IPP custom DLL sample, it is useful as it prints version of IPP loaded by dispatcher including cpu specific prefix

Vladimir

I'll give it a try.

To reproduce the problem, we ordered one of these:

http://www.newegg.com/Product/Product.aspx?Item=N82E16883107727

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

jnoring · ‎11-27-2008

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;

    IppiRect sourceRect;
    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);

	delete[] pImageData;
	delete[] pScaledData;

	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.

Vladimir_Dudnik · ‎12-02-2008

Ok, we'll wait info from you after holydays.

Vladimir

jnoring · ‎12-08-2008

Quoting - vdudnik

Ok, we'll wait info from you after holydays.

Vladimir

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.

Vladimir_Dudnik · ‎12-09-2008

Thanks for providing update on this.

Sorry for inconvenience, you know, things happens. But you may rely on Intel product support. If there is some critical issue detected against IPP product we will provide special update which fix this.

Regards,
Vladimir

j_miles · ‎08-21-2009

Quoting - Vladimir Dudnik (Intel)

Thanks for providing update on this.

Sorry for inconvenience, you know, things happens. But you may rely on Intel product support. If there is some critical issue detected against IPP product we will provide special update which fix this.

Regards,
Vladimir

When was this exactly fixed? I mean, it has now been confirmed to work with IPP v. 5.3.4 whereas the 5.3.1 failed. How about the two "in-betwen" updates (i.e. 5.3.2 and 5.3.3)?

In the release-notes for IPP 5.3.4 it is stated that "Corrected CPU dispatching result on Intel Core 2 Duo mobile processors based system". Note the "mobile" (emphasized by me) - the E5200 can hardly be called a mobile processor, but is this referring to the same issue (so that it is first fixed in v.5.3.4 and not before)?

We have a customer now that may experience a similar problem with the E5200 processor, so I could really appreciate any input (as fast as possible).

Thanks.

- Jay

Vladimir_Dudnik · ‎08-21-2009

Hello Jay,

I think the issue with dispatcher was fixed in IPP 5.3 update 4, just was not completey correct described in release notes. In any case, IPP 5.3 should be binary compatible with all updates made for 5.3 version, so you should be able safely apply update 4

Regards,
Vladimir

j_miles · ‎08-21-2009

Quoting - Vladimir Dudnik (Intel)

Hello Jay,

I think the issue with dispatcher was fixed in IPP 5.3 update 4, just was not completey correct described in release notes. In any case, IPP 5.3 should be binary compatible with all updates made for 5.3 version, so you should be able safely apply update 4

Regards,
Vladimir

Hi Vladimir,

Thanks for the heads up. Now I'm looking at a distribution that is based on static linkage (with dispathing, obviously) and I checked that it is based on IPP 5.3.3. Can you confirm that the incorrect E5200 dispatching is in 5.3.3 as well (so we have to update to 5.3.4 to get rid of it)?

Thanks.

- Jay

Chao_Y_Intel · ‎08-23-2009

HI Jay,

Youneed to update to IPP 5.3 update 4 or later version. Check the articles here:

http://software.intel.com/en-us/articles/intel-integrated-performance-primitives-intel-ipp-intel-ipp-53-dispatches-wrong-cpu-type-for-intel-core2-duo-mobile-processors/

Thanks,
Chao

j_miles · ‎08-24-2009

Hi Chao,

Great - thanks for the confirmation. (And not so great - we will need to update...).

Anyway, I would suggest you to update the information provided in the article you linked to. As this forum thread shows, it also affects "non-mobile" processors, which should be emphasized in the article.
(BTW: Can I subscribe to such articles to get the information early on?).

Thanks.

- Jay

j_miles · ‎08-24-2009

Hi Chao,

I have a hard time finding an E5200 here at the offices and we can not get access to the customer system (for good reasons). Would it be possible to get a list of all affected processor models to see if we have ana atlernative for testing purposes?

Thanks.

- Jay

Ying_H_Intel · ‎11-24-2010

Just list all affected recessor we knew so far.

ProcessorPentium Dual-Core CPU E5700 @ 3.00GHz, 3003 Mhz, 2 Core(s), 2 Logical Processor(s)
ProcessorPentium Dual-Core CPU E5200 @ 2.50GHz, 2493 Mhz, 2 Core(s), 2 Logical Processor(s)
ProcessorPentium Dual-Core CPU E5300 @ 2.60GHz, 2603 Mhz, 2 Core(s), 2 Logical Processor(s)
ProcessorPentium Dual-Core CPU T4200 @ 2.00GHz, 2000 Mhz, 2 Core(s), 2 Logical Processor(s)
Intel CoreTM 2 Duo CPUT7300,Core 2 DuoCPU E6300. (Core 2 Duo E6400 work ok).

Users can do quick detect to find if the process is affected or not.
For example, on E6300 (which only support SSSE3). if call ippGetCpuType(), it return ippCPUSSE42, which is wrong.

ippStaticInit() => 0
IppLibraryVersion() => 5.3.85.461 - ippcorel.lib 5.3 build 85.13 Oct 8 2007
ippGetCpuType() => 0x44 (i.e. ippCpuSSE42!!)
ippStaticInitCpu(0x44) => 0

Moreover, regardingthe affected IPP function list, almost all ofIPP functions are affected due to this bug in ipp5.3.x as SSE4 code is dispatched. Of course some functions can work on these cpus as doesn't contain any SSE4 instructions, but a lot of functions use SSE4 instructions as they use SSE4 intrinsic and assembler instructions as well as are compiled with compiler switch that allows SSE4 code generation. Soifany similiar issue, pelaseswitch to ipp5.3.4 (or any 6.1 update or 7.0) where this bug has been already fixed.

Hope it helps
Regards,
Ying

j_miles · ‎11-26-2010

Hi Ying,

Good information - thanks. We are in the process of switching everything to IPP v. 6.1 (and later v. 7.0) so we will avoid the issue.

Best regards,

- Jay