topic Access violation in ippiWarpBilinear in Intel® Integrated Performance Primitives

Access violation in ippiWarpBilinear

Nielsen__Troels — Fri, 05 Jul 2019 12:49:10 GMT

Hi,

I am getting access violations in ippiWarpBilinear_8u_C1R when run on certain inputs. I am currently testing this with IPP 2018 - Initial Release.

I have boiled it down to this minimal example:

const auto srcSize = IppiSize{ 8439, 54 };
const auto srcRoi = IppiRect{ 2577, 0, 1393, 54 };
const auto srcStep = srcSize.width;
const auto pSrc = ippsMalloc_8u(srcSize.width * srcSize.height);
if (!pSrc)
		throw std::runtime_error("Allocating src failed");

const auto dstSize = IppiSize{ 42, 1386 };
const auto dstRoi = IppiRect{ 0, 0, dstSize.width, dstSize.height };
const auto dstStep = dstSize.width;
const auto pDst = ippsMalloc_8u(dstSize.width * dstSize.height);
if (!pDst)
	throw std::runtime_error("Allocating dst failed");

const double coeffs[2][4] =
{
	{2.06479e-05, -0.00055722, -0.827145, 42.5322},
	{5.86368e-11, 0.995243, -2.34897e-06, -2563.82},
};

int bufferSize = -1;
const auto resultBufferSize = ippiWarpBilinearGetBufferSize(srcSize, srcRoi, dstRoi, ippWarpForward, coeffs, IPPI_INTER_LINEAR, &bufferSize);
if (resultBufferSize != ippStsNoErr)
	throw std::runtime_error("Getting buffer size failed");

const auto pBuffer = ippsMalloc_8u(bufferSize);
if (!pBuffer)
	throw std::runtime_error("Allocating buffer failed");

const auto resultWarp = ippiWarpBilinear_8u_C1R(pSrc, srcSize, srcStep, srcRoi, pDst, dstStep, dstRoi, coeffs, IPPI_INTER_LINEAR, pBuffer);
if (resultWarp != ippStsNoErr)
	throw std::runtime_error("Warp failed");

Am I doing something wrong here?

Best regards,

Troels

Probably You wanted to set

Gennady_F_Intel — Fri, 05 Jul 2019 16:34:47 GMT

Probably You wanted to set const auto dstSize = IppiSize{ 1386, 42 }; instead of //const auto dstSize = IppiSize{ 42, 1386 };

Well, so long as the pointers

Nielsen__Troels — Mon, 08 Jul 2019 10:05:00 GMT

Well, so long as the pointers and sizes are valid I shouldn't get an access violation, right?

I have run a lot of tests to further pin down the issue. It looks as if the access violation is happening when the map is nearly affine, i.e. coeffs[0][0] and coeffs[1][0] are close to zero.

Is anyone looking into this?

Nielsen__Troels — Mon, 29 Jul 2019 07:36:12 GMT

Is anyone looking into this? Can anyone replicate it?

Unless there is an issue with my code above, this has to be an internal bug in ippiWarpBilinear.

We are currently forced to detect coefficients that are likely to cause the access violation but in the long run this is not a viable solution for us.

Please advise.

Hello, Troels!

Ivan_G_Intel1 — Tue, 30 Jul 2019 07:29:59 GMT

Hello, Troels!

Thank you for your feedback. We have investigated this issue. It's an internal bug in IPP which will be fixed in the upcoming releases.

Best regards,
Ivan Galanin.

Hi Ivan,

Chan__Davy — Mon, 11 Nov 2019 05:39:46 GMT

Hi Ivan,

I encounter the same problem when I use this warp function. I updated to the latest version but still have this error. May I know when we will get the version with the fix. Is there a short term solution to avoid this problem? Thanks.

Best regards,
Davy

Hi, Davy!

Ivan_G_Intel1 — Mon, 11 Nov 2019 07:22:09 GMT

Hi, Davy!

It seems that you have opened another thread, lets discuss the topic there.

Best regards,
Ivan Galanin.

Hi Davy,

Ruqiu_C_Intel — Tue, 12 Nov 2019 01:54:00 GMT

Hi Davy,

The sample code which Troels provided above works well in my site with IPP 2019 update 4. Your question might be different with this one, so let's discuss it in the new opened thread.

Best Regards,

Ruqiu

Hi,

Nielsen__Troels — Tue, 12 Nov 2019 10:20:57 GMT

Hi,

I just ran my test with the new version (ippCore 2019.0.5 (r0xc95fdf5f)). Unfortunately it still fails on my system with an access violation.

Best regards,

Troels

Troels,

Gennady_F_Intel — Tue, 12 Nov 2019 15:15:09 GMT

Troels,

I also tried the latest IPP 2019 u5 on my part ( win 10, 64 bit, static linking with multithreading libs ) and see no problem so far.

I added this code at the very end of this example

.....
if (resultWarp != ippStsNoErr)
throw std::runtime_error("Warp failed");

const IppLibraryVersion* lib = ippsGetLibVersion();
   printf("\t ======================================================================== \n");
printf("\t\t version of IPP is: %s %s %d.%d.%d.%d\n", lib->Name, lib->Version,
   lib->major, lib->minor, lib->majorBuild, lib->build);
   printf("\t ======================================================================== \n");
and here is the output I see:

.test.exe
========================================================================
version of IPP is: ippSP AVX2 (l9) 2019.0.4 (r62443) 2019.0.4.62443
========================================================================

Could you give us the same

Gennady_F_Intel — Tue, 12 Nov 2019 15:15:48 GMT

Could you give us the same output?

If I build for x86 I get:

Nielsen__Troels — Tue, 12 Nov 2019 17:35:43 GMT

If I build for x86 I get:

         ========================================================================
                 version of IPP is:   ippSP AVX2 (h9) 2019.0.5 (r0xc95fdf5f) 2019.0.5.-916463777
         ========================================================================

And for x64:

         ========================================================================
                 version of IPP is:   ippSP AVX2 (l9) 2019.0.5 (r0xc95fdf5f) 2019.0.5.-916463777
         ========================================================================

I have attached the complete source code. I am also running Win10 64 bit. My CPU is a Core i7 4900MQ. The access violation happens in both x86 builds and x64 builds.

I went one step further and added an exception handler for the access violation. I have attached another version of the source code that performs a bit of address randomization and logs the relative addresses etc.

In x86 the access violation always occurs in ippih9.dll at 0x00c6f8b2 when trying to read pSrc - 5129.
In x64 it is in ippil9.dll at 0x00ecb98c when it trying to read pSrc + 36245229014254.
I hope this is useful somehow.

Best regards,
Troels

ok, we will check with IPP

Gennady_F_Intel — Wed, 13 Nov 2019 04:31:00 GMT

ok, we will check with IPP 2019 u5 as the previous test I linked against IPP 2019 u4.

could you also show us how did you link this case?

To link it I added the prober

Nielsen__Troels — Wed, 13 Nov 2019 07:24:08 GMT

To link it I added the prober library directory, e.g. compilers_and_libraries_2019.5.281\windows\ipp\lib\ia32_win and then I used pragmas:

#pragma comment(lib, "ippi.lib")
#pragma comment(lib, "ipps.lib")

Ok, thanks. The fix of this

Gennady_F_Intel — Wed, 13 Nov 2019 15:28:15 GMT

Ok, thanks. The fix of this issue would be available to the nearest release of IPP v.2020. We will keep this forum thread updated when this release would happen.

Re: Ok, thanks. The fix of this

Nielsen__Troels — Thu, 25 Feb 2021 09:13:33 GMT

Hi,

I am still experiencing this issue in version 2020. I used the same source code as before but the CPU is now an i9-10980HK.

In x86 builds the version info returned is ippSP AVX2 (h9) 2020.0.3 (r0x3390eac5) 2020.0.3.865135301. The access violation occurs at 0x00d143b8 in ippih9.dll.

In x64 builds the version info returned is ippSP AVX2 (l9) 2020.0.3 (r0x3390eac5) 2020.0.3.865135301. The access violation occurs at 0x00f7209e in ippil9.dll.

The address that it is trying to read from is pSrc - 5069 in x86 and pSrc + 36245229014314 in x64.