BUG in ippiDemosaicAHD_16u_C1C3R?

[Stefan_B_3]

Dear Support Team,

I did report a bug in the function ippiDemosaicAHD_8u_C1C3R (https://community.intel.com/t5/Intel-Integrated-Performance/BUG-in-ippiDemosaicAHD-8u-C1C3R/m-p/1145618) some years ago that has been fixed but it seems there is still another issue with the 16-bit version of the function! We have encountered various reads to memory locations slightly BEFORE the pointer passed as pSrc. Please see attached screenshot. The system we did encounter this with runs a Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz. We first saw this when running tests with the Clang Thread Sanitizer but this also happens without the sanitizer active. Now since this is an invalid read in contrast to the other issue I did report (invalid write) I cannot provide an example showing a heap corruption. What is important however is that this only seems to happen when the width of the source image is exactly as 5 which is the minimal supported source image width as stated by the documentation. The height doesn’t seem to matter. pSrc in case of the crash was 0x7b980000000. We mostly saw read attempts to exactly one byte before ‘pSrc’ but in this case it was 16.

Please have a look! I will provide more information as needed. We are currently running IPP 2021.2

Regards,

Stefan

[VidyalathaB_Intel]

Hi Stefan,

Thanks for reaching out to us.

>>We are currently running IPP 2021.2

Could you please give it a try with the newer IPP version which is 2021.5.0 and confirm whether you are getting the same behavior even with the latest version?

If you still see the same behavior, please get back to us with the sample reproducer so that we can test it from our end as well.

Regards,

Vidya.

[Stefan_B_3]

Dear Vidya,

seems the problem is still there. Please see attached code snippet explaining what the actual problem is. Please also note that this example will most likely NOT crash when you run it. We only get sporadic SEGVs on Linux depending on where the piece of memory gets allocated. In fact we mainly see this when NOT using your allocation functions but I think this is just a coincidence. I assume for very small images the edge treatment of the algorithm might not be correct and the algorithm will use one or multiple bytes outside the actual image for whatever interpolation internally done. So I think one must debug and carefully examine the addresses that are read while processing the image.

Hope that helps,

regards,

Stefan

[Gennady_F_Intel]

Stefan,

we validated the test you shared with the current 2021.5 version and didn't manage to see the problem you reported. We tested this case on RHEL7, 64 bits with AVX2(L9) and AVX-512(k0) code paths.

Running the code during the 40 min calls ( > 250000 times) we see no segfaults here.

The examples of 10K logs (_avx2_ipp2021u5.res _avx512_ipp2021u5.res ) are attached.

[Gennady_F_Intel]

the 10 K times testing results are attached. 

[Stefan_B_3]

Dear Gennady,

thanks for testing. We also just get this veeery rarely. I think the challenge is to trigger the debugger here. I assume that whether it crashes or not is extremely dependent on where on the heap the image buffer is allocated. When we see this usually we have various buffers for various images in memory and the crash usually occurs on the one with the lowest address. Maybe the runtime just notices it when certain heap boundaries are violated but this is guesswork only. You could replace the allocated memory address of the source image by a hardcoded invalid one. We did that as well (e.g. just pass 0x0000000078000000) as the address of the source image even though it is invalid. Even then depending on the address sometimes it gives a segv not within the invalid region but at 0x77FFFFFF. But most of the time of course it crashes within the invalid address region because ... well it is invalid. So this can also be very cumbersome. Maybe it is easier to have a look at the way your algorithm treats the upper left corner of the image... I know this might be a tough one. We just changed our code in a way that when the image is less than 6 pixels wide in X or Y direction we use our own De-Bayer algorithm since for images that small HQ De-Bayering is of limited use anyway. Since then we have no more issues.

Regards,

Stefan

[Stefan_B_3]

Any news on this one?