- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Unhandled exception at 0x04caa7d1 in xxxxxxx.exe: 0xC0000005: Access violation reading location 0x087f6000.
DPD200227775 ippiResizeYUV422_8u_C2R bug
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
[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.
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 :)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks to allfor your efforts! And special thank for example of code!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Looking forward for the next IPP update.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page