CopySubpix problem

[jon_shadforth]

IPP6.1.5.054, 64-bit on Windows 7 64-bit

Am getting occasional crashes (access violation) usingippiCopySubpix_8u_C1R. I've just managed to replicate this using the demo application (ippiDemo_em64t.exe) and I have some code that will reproduce it quite quickly. (I've deliberately left out ippiFree because I need to get lots of different pointers before the crash occurs).

for(int i = 0; i < 1000; i++)

{

IppiSize ippiSize = { 1024, 4 };

Ipp8u* image1 = (Ipp8u*)ippMalloc(ippiSize.width * ippiSize.height);

Ipp8u* image2 = (Ipp8u*)ippMalloc(ippiSize.width * ippiSize.height);

ippiCopySubpix_8u_C1R(image2, ippiSize.width, image1, ippiSize.width, ippiSize, 0, 0);

}

When the access violation occurs the disassembler shows:

movzx r15d,byte ptr [r11+r10+1]

Where...

r10 = image2 + (1024 * 4)

r11 = 799

So it looks like it's trying to read data below the last valid line of image2.

To replicate this in the demo app I created 8 8U images at 660*496 pixels, then used the CopySubpix function with manual destination image selection enabled, and tested copying from image 8 to 7, then 6 to 5, and I think at copy from 4 to 3 it popped up an access violation message.

I can't see any other reference to this in the forum, nor is it listed in any of the bug fixes.

Any help appreciated - Jon.

[Gennady_F_Intel]

Jon, I couldn't reproduce the problem with the latest version - 7.0 update 6. Please get the evaluation version on check on your side.

[SergeyKostrov]

Quoting jon_shadforth

IPP6.1.5.054, 64-bit on Windows 7 64-bit

...
(I've deliberately left out ippiFree because I need to get lots of different pointers before the crash occurs).

for(int i = 0; i < 1000; i++)

{

IppiSize ippiSize = { 1024, 4 };

Ipp8u* image1 = (Ipp8u*)ippMalloc(ippiSize.width * ippiSize.height);

Ipp8u* image2 = (Ipp8u*)ippMalloc(ippiSize.width * ippiSize.height);

ippiCopySubpix_8u_C1R(image2, ippiSize.width, image1, ippiSize.width, ippiSize, 0, 0);

}

...
Any help appreciated - Jon.

Could you try a test with verifications of 'image1' and 'image2' pointersas follows:

...
for( int i = 0; i < 1000; i++ )
{
IppiSize ippiSize = { 1024, 4 };
Ipp8u* image1 = (Ipp8u*)ippiMalloc(ippiSize.width * ippiSize.height);
if( image1 == NULL )
{
printf( "Failed to allocate memory for Image1\n" );
break;
}
Ipp8u* image2 = (Ipp8u*)ippiMalloc(ippiSize.width * ippiSize.height);
if( image2 == NULL )
{
printf( "Failed to allocate memory for Image2\n" );
break;
}
ippiCopySubpix_8u_C1R(image2, ippiSize.width, image1, ippiSize.width, ippiSize, 0, 0);
}
...

I don't think that the problem with access violation is related to a "lack of memory" on a 64-bit Windows 7 because ~31MB of memory is allocated
after 1,000 interations in Jon's test case.

Best regards,
Sergey

[jon_shadforth]

I've re-tested this on another PC running the latest IPP 7 (rev 6), it still crashes.

disassembler: movq xmm5,mmword ptr [eax+esi+8]
image2 = 16317472
esi = 16321528
eax = 1024
image size in bytes = 1024 * 4 = 4096
image2 + image size = 16321568

The address being used at the point of failure = [1024 + 16321528 + 8] = 16322560
So the reason for the crash is the algorithm is trying to read memory (16322560) that is beyond the end of image 2 (16317472 to 16321567)

If my understanding is correct then the algorithm is sampling data outside of the image bounds. This makes sense when you think of the fractional offsets being used. But this also means that the documentation is incorrect by not stipulating that the ROI should take into account this effect (as we do for most kernel operations). It also means the demo app has the same bug that I do because it also processes the entire region of an image. (The demo app can be made to crash using this function).

So my current conclusion is that the documentation is wrong, and that my software and your demo need to be fixed. For the moment I have to stop using the function as I have alternatives (such as the affine transformation) that work for my full ROI.

Any more feedback on this much appreciated.

[SergeyKostrov]

Quoting jon_shadforth

...
If my understanding is correct then the algorithm is sampling data outside of the image bounds...
...
Any more feedback on this much appreciated.

I think Intel Software Engineers should look at the problem.

One more thing, could you try to increasethe sizeof a buffer that holds the second image:
...
int iExtra = 128; // Number of Extra Rowsand Cols

Ipp8u* image2 = (Ipp8u*)ippiMalloc( ( ippiSize.width +iExtra )* (ippiSize.height + iExtra ));
...

[jon_shadforth]

Tested - increasing the size of the destination image by one row (1024 bytes in this case) stops the access violation.