topic Yet another bug in ippiResizeYUV422_8u_C2R function in Intel® Integrated Performance Primitives

Yet another bug in ippiResizeYUV422_8u_C2R function

martishka — Fri, 30 Dec 2011 16:00:31 GMT

Hi,

I have the following problem:

I'm usingippiResizeYUV422_8u_C2R to resize oneYUV buffer withIPPI_INTER_SUPER interpolation method and the program crashes with error:

Unhandled exception at 0x04caa7d1 in xxxxxxx.exe: 0xC0000005: Access violation reading location 0x087f6000.

This location is just after the buffer end (which in my case comes from DirectShow). If otherinterpolation is used or less lines are resized everything is OK.

I saw that Update 6 had a bugfix for this function

DPD200227775 ippiResizeYUV422_8u_C2R bug

but after the update the problem persisted.

Is this a known bug/limitation?

PS: This function seems to be is verybuggy :)))

Yet another bug in ippiResizeYUV422_8u_C2R function

igorastakhov — Sun, 08 Jan 2012 09:00:36 GMT

Hi,

please provide a reproducible example - you should prove that problem is in the function and not because of wrong parameters/buffer sizes used.

Regards,
Igor

Yet another bug in ippiResizeYUV422_8u_C2R function

martishka — Mon, 09 Jan 2012 09:00:03 GMT

Well areproducible example will be quite hard (and long) to supply but will try to describe it.

I have a DirectShow graph with sample grabber (video) for collecting video frames. From the grabber I receiveIMediaSample from which I get a pointer the to video frame (IMediaSample::GetPointer). The video from the grabber is YUY2 and I useippiResizeYUV422_8u_C2R to resize the frame to the desired size.

When I use theIPPI_INTER_SUPER interpolation method the function fails (withIPPI_INTER_NN,IPPI_INTER_LINEAR andIPPI_INTER_CUBIC everything is OK).

For test I allocated a buffer the exact same size as the one fromIMediaSample (and moved the video frame it in) and passed it the resize function (with IPPI_INTER_SUPER)and everything was fine. So my guess ippiResizeYUV422_8u_C2R reads outside the buffer which leads to a crash when the buffer is in a more "sensitive" memory space.

If the problem was inwrong parameters/buffer sizes the function will be crashing all the time.

Regards,

Martin.

Yet another bug in ippiResizeYUV422_8u_C2R function

SergeyKostrov — Tue, 10 Jan 2012 00:53:24 GMT

Quoting martishka

Well areproducible example will be quite hard (and long) to supply but will try to describe it.

[SergeyK] I really recommend you to createsome numberTest-Cases.

I have a DirectShow graph with sample grabber (video) for collecting video frames. From the grabber I receiveIMediaSample from which I get a pointer the to video frame (IMediaSample::GetPointer). The video from the grabber is YUY2 and I useippiResizeYUV422_8u_C2R to resize the frame to the desired size.

When I use theIPPI_INTER_SUPER interpolation method the function fails (withIPPI_INTER_NN,IPPI_INTER_LINEAR andIPPI_INTER_CUBIC everything is OK).

If the problem was inwrong parameters/buffer sizes the function will be crashing all the time.

Regards,

Martin.

Hi Martin,

You'veimplementedsome codesthat useDirectShowand IPP APIs. In general, you need some number
of isolated Test-Cases in order to understand which one creates the problem. You need to find a root-cause
of the problem and, from my point of view, it is very hard to findwithout isolated Test-Cases.

Here are some ideas for Test-Cases:

- an isolatedTest-Case for all IPP functions you use
- an isolated Test-Case for all DirectShow COM-Interfaces
- an isolated Test-Case that verifies that there are no any memory management problems

In your case, the worst thing is when there are some problems in all three areas, that is, DirectShow, IPP and amemory management.

Even if some problem is confirmed, for example with IPP,it doesn't meanthat there are no problems with
DirestShow or, with another part of your codes.

Best regards,
Sergey

Yet another bug in ippiResizeYUV422_8u_C2R function

levicki — Wed, 18 Jan 2012 00:21:19 GMT

Guys, when you are doing regression testing, are you testing all interpolation methods? Are you absolutely sure that all of them wok?

Yet another bug in ippiResizeYUV422_8u_C2R function

igorastakhov — Wed, 18 Jan 2012 07:53:43 GMT

Igor,

your question is marked as reply to post #3 - so is it a question for Sergey? If so - you've selected the wrond address - Sergey doesn't have any relations to IPP development and testing, but (thanks to Sergey) he provides a lot of support for different customerson a big variety of questions related IPP.

As regarding your question - nobody can say that some sw product is completely and comprehensivelytested for all possible cases of use... Anyway each IPP function has several algprithmic (algorithm itself, thread safe, membound, misalignment, badarg, secial cases, etc.) and performance tests with nested loops by all parameters. "regression" in our terminology means tests suite extension with cases not covered by existing tests and reported by validation team or internal/external customers. So if it's proved that this particular function has a bug that is not detected by our testsys - the suite for it will be extended with special "regression" test. Have I answered your question?

regards,
Igor

Yet another bug in ippiResizeYUV422_8u_C2R function

martishka — Wed, 18 Jan 2012 08:43:18 GMT

Quoting Igor Levicki

Guys, when you are doing regression testing, are you testing all interpolation methods? Are you absolutely sure that all of them wok?

Will in the test app I posted earlier:

#include "stdafx.h"
#include "ipp.h"
#include "windows.h"

int IMG_WIDTH = 384;
int IMG_HEIGHT = 288;
int IMG_SIZE = IMG_WIDTH * IMG_HEIGHT * 2;

int IMG_RESIZE_WIDTH = 148;
int IMG_RESIZE_HEIGHT = 111;
int IMG_RESIZE_SIZE = IMG_RESIZE_WIDTH * IMG_RESIZE_HEIGHT * 2;

int _tmain(int argc, _TCHAR* argv[])
{
Ipp8u* pSrc = (Ipp8u*) VirtualAlloc( NULL, IMG_SIZE, MEM_COMMIT, PAGE_READWRITE );
memset( pSrc, 0, IMG_SIZE );
Ipp8u* pDst = (Ipp8u*) malloc( IMG_RESIZE_SIZE );
memset( pDst, 0, IMG_RESIZE_SIZE );

IppiSize sz = { IMG_WIDTH, IMG_HEIGHT };
IppiRect srcRect = { 0, 0, IMG_WIDTH, IMG_HEIGHT };
IppiSize dstSize = { IMG_RESIZE_WIDTH, IMG_RESIZE_HEIGHT };

ippiResizeYUV422_8u_C2R( pSrc, sz, IMG_WIDTH * 2, srcRect, pDst, IMG_RESIZE_WIDTH * 2,
dstSize,(double)IMG_RESIZE_WIDTH/(double)IMG_WIDTH,
(double)IMG_RESIZE_HEIGHT/(double)IMG_HEIGHT, IPPI_INTER_SUPER );

return 0;
}

It is quite simple to change the interpolation method and it is only crashing with SUPER.

PS: I found a similar issuehttp://software.intel.com/en-us/forums/showthread.php?t=85430&o=a&s=lrsaying that the problem will be fixed in update 6. Sadly after I updated to 6 I found that is wasn't :)

Regards,

Martin.

Yet another bug in ippiResizeYUV422_8u_C2R function

levicki — Wed, 18 Jan 2012 17:20:11 GMT

Hello,

Question was for Sergey and you. I apologize if he is not involved. I asked about regression testing because customer was complaining that there was a similar bug before that was supposedly fixed.

I will compile and test the code they provided to see if I can reproduce it using Composer Update 8.

EDIT:

I have compiled and tested -- I am getting a crash in ippig9-7.0.dll at RVA 0x1094A02B. Offending instruction is:

movzx edi, byte ptr [ecx+ebx*4]

At the time of crash, ecx contains address of pSrc + IMG_SIZE - (IMG_WIDTH * 2), while ebx contains 0xC0 which multiplied by 4 results in 0x300 which is IMG_WIDTH * 2, or exactly size of one row (768 bytes).

If you add that to the value above you get read access which is one byte past the end of source buffer.

I cannot but notice that ESI register which is used as a loop conditional contains 0xC3 (0x30C / 4) which is 12 bytes off from the real row size.

I also checked the function documentation and I fail to see what the customer might be doing wrong here.

Yet another bug in ippiResizeYUV422_8u_C2R function

Ivan_Z_Intel — Thu, 19 Jan 2012 07:30:20 GMT

The bug in function ippiResizeYUV422_8u_C2R is fixed. This changewill be accessed in next verison.
Thanks to allfor your efforts! And special thank for example of code!

Yet another bug in ippiResizeYUV422_8u_C2R function

martishka — Thu, 19 Jan 2012 10:13:16 GMT

Glad to hear the bug is fixed.

Looking forward for the next IPP update.

Regards,

Martin.