Yet another bug in ippiResizeYUV422_8u_C2R function

Yet another bug in ippiResizeYUV422_8u_C2R function

martishka's picture

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 :)))
10 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
igorastakhov's picture

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

martishka's picture

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.

Sergey Kostrov's picture
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). 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.

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

Igor Levicki's picture

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

-- Regards, Igor Levicki If you find my post helpfull, please rate it and/or select it as a best answer where applies. Thank you.
igorastakhov's picture

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

martishka's picture
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.
Igor Levicki's picture

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.

-- Regards, Igor Levicki If you find my post helpfull, please rate it and/or select it as a best answer where applies. Thank you.
IVAN Z. (Intel)'s picture

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!

martishka's picture

Glad to hear the bug is fixed.

Looking forward for the next IPP update.

Regards, Martin.

Login to leave a comment.