- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Probably You wanted to set const auto dstSize = IppiSize{ 1386, 42 }; instead of //const auto dstSize = IppiSize{ 42, 1386 };
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Davy!
It seems that you have opened another thread, lets discuss the topic there.
Best regards,
Ivan Galanin.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
========================================================================
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could you give us the same output?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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")
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page