Intel® Integrated Performance Primitives
Deliberate problems developing high-performance vision, signal, security, and storage applications.
6709 Discussions

Yet another bug in ippiResizeYUV422_8u_C2R function

martishka
Beginner
935 Views
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 :)))
0 Kudos
9 Replies
igorastakhov
New Contributor II
935 Views
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
0 Kudos
martishka
Beginner
935 Views
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.
0 Kudos
SergeyKostrov
Valued Contributor II
935 Views
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

0 Kudos
levicki
Valued Contributor I
935 Views
Guys, when you are doing regression testing, are you testing all interpolation methods? Are you absolutely sure that all of them wok?
0 Kudos
igorastakhov
New Contributor II
935 Views
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
0 Kudos
martishka
Beginner
935 Views
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.
0 Kudos
levicki
Valued Contributor I
935 Views
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.

0 Kudos
Ivan_Z_Intel
Employee
935 Views
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!
0 Kudos
martishka
Beginner
935 Views
Glad to hear the bug is fixed.

Looking forward for the next IPP update.

Regards,
Martin.
0 Kudos
Reply