- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I just recently noticed, that ippiFilterBox_32f_C1R can access data beyond the input buffers limits (including external border). Usually this does not cause much of a problem, but of course sometimes this can lead to an access violation. E.g. Microsofts Application Verifier can detect the issue reliably. I can reproduce with IPP 7.1 and 8.0.
An excerpt from the code triggering the problem:
void Convolution::conv2Box_IPP(Ipp32f* in, Ipp32f* out, int dataSizeX, int dataSizeY, int kSize) { IppiSize inSize = { dataSizeX, dataSizeY }; IppiSize outSize = { dataSizeX - kSize + 1, dataSizeY - kSize + 1 }; IppiSize boxSize = { kSize, kSize }; IppiPoint anchor = { (kSize - 1) / 2, (kSize - 1) / 2}; int inStep = dataSizeX * sizeof(Ipp32f); int outStep = dataSizeX * sizeof(Ipp32f); Ipp32f* inOffset = in + inSize.width * anchor.y + anchor.x; Ipp32f* outOffset = out + inSize.width * anchor.y + anchor.x; ippiFilterBox_32f_C1R(inOffset, inStep, outOffset, outStep, outSize, boxSize, anchor); } //... float* a = new float[sizeY * sizeX]; float* ai = new float[sizeY * sizeX]; //... Convolution::conv2Box_IPP(ai, a, sizeX, sizeY, filterSizeRho);
The input sizes are something like 400x300. The filter size equals 11 or 31.
Is this a bug in ippiFilterBox? Only in ippiFilterBox?
Must I use the ippiMalloc functions when working with ippiFilter functions? This would add quite a bit extra complexity and overhead - as the input buffer is passed in as an argument - the caller should not need to know I use IPP internally.
Any thoughts on this?
regards
Harald
PS: The Application Verifier catches the access at ippip8-8.0.dll!0956b1d0() ; ippip8-8.0.dll loaded at 08C40000-098D5000*
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Harald,
thank you for catching this - this is a real bug, will be fixed in the next IPP version (if there will be no decision to remove all deprecated functionality from the main package). As a workaround it is recommended to use ippiFilterBoxBorder function, moreover - ippiFilterBox is deprecated one.
regards, Igor
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FilterBox will try to access pixels around each one on the target, so they would better exist in the source (it used to bug me as well). This is something that the new FilterBoxBorder doesn't do (but can still do).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The size and input-pointers are adjusted to take the kernel size into account. Still the access occurs beyond the buffer.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Harald,
thank you for catching this - this is a real bug, will be fixed in the next IPP version (if there will be no decision to remove all deprecated functionality from the main package). As a workaround it is recommended to use ippiFilterBoxBorder function, moreover - ippiFilterBox is deprecated one.
regards, Igor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Igor Astakhov (Intel) wrote:
this is a real bug
Is it? Maybe I read the code wrong, then.
Is it only affecting the _32f_C1R
version?
I've never met the problem in the 8u versions, but it's also possible that it just hasn't been caught because of lucky memory allocation.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page