problems with ippiMalloc_8u_C4()

Andres_G_1 — Tue, 08 Dec 2015 22:32:25 GMT

I am having all sorts of pain chasing down a bug that crashes my app when exiting, that is, when I call all of the destructors and exit. Using gdb, I have noticed something that seems strange to me. When I first call ippiMalloc_8u_C4() I get a very large/high pointer, but subsequent calls return much lower memory. For example, my log will look like this:

Dec 08 16:04:29.038 ***: ippiMalloc() returning ptr: 0x7f6a09347040
Dec 08 16:04:29.053 ***: ippiMalloc() returning ptr: 0x2e8f9c0
Dec 08 16:04:29.057 ***: ippiMalloc() returning ptr: 0x269ed80

and all subsequent calls (about 20) will return points similar to the last 2 above -- only the very first call to ippiMalloc() returns a large/high pointer. This seems to be related to my crash bug, because I get a segfault in my logging functions on either the 2nd or 3rd free during shutdown. That is, when I call ippiFree() on the first large pointer (and sometimes the second smaller pointer above) all is fine. However, when I call ippiFree() on the 3rd pointer (and sometimes on the 2nd pointer), I get a segfault. When I run separate test code on the objects that allocate that memory, I never get the large pointer on the first allocation (that is, all of the allocations yield the small/lower pointers) and I never get a segfault during shutdown.

Question #1: what does ippiMalloc() do that would cause such variation in the size/location of the returned pointer. Is this expected behavior?

Question #2: If both width and height are multiples of 64, will the memory returned my ippiMalloc() ever be discontinuous? That is, will the beginning of a new line always immediately follow the end of the previous line? Some posts on this forum indicate that both the W and H will be aligned. Will that alignment result in gaps in the memory? That is, the follow code assumes contiguous memory without any gaps due to alignment but would break if rows had to be aligned:

int nImageSize = nWidth * nHeight * 4; // for BGRA, 4 bytes per pixel

for (int i = 0; i < nImageSize; ++i) *pDst++ = *pSrc++;

Question #3: If I am processing BGRA images, should I use ippiMalloc_8u_C4() and just cast it to an int pointer? For example like this:

uint32_t *pImage = (uint32_t *) ippiMalloc_8u_C4(width, height, &step);

this is somewhat confusing because you do not provide a: ippiMalloc_32u_C4() only a signed version.

Thanks for any help,

-Andres

Andres,

Chao_Y_Intel — Fri, 18 Dec 2015 04:33:00 GMT

Andres,

ippiMalloc just calls the system malloc function to allocate the memory. If the memory address is not aligned, IPP is may call malloc function to a allocate a few more bytes, and return an aligned memory address. So for you question 1)such address may not be expected. so it needs to check if any code error there. (2) if the width is the multiples of 64. It will use the continuous memory between the lines. You can check the step size, it is expected to the same as the width* pixel size. (3) it ca use ippiMalloc_8u_C4(). For 8u_C4() function in the IPP, it means the image has 4 four channels(BGRA), each channel is 8 bytes.

But if you define the image as “uint32_t”, the following code has the problem:

int nImageSize = nWidth * nHeight * 4; // for BGRA, 4 bytes per pixel
for (nti = 0; i < nImageSize; ++i) *pDst++ = *pSrc++;

it change either of the following code:
uint32_t *pImage ;
for (nti = 0; i < nWidth * nHeight; ++i) *pDst++ = *pSrc++;

or:

Ipp8u *pImage ;
for (int i = 0; i < nWidth * nHeight*4; ++i) *pDst++ = *pSrc++;

Thanks,
Chao

topic Andres, in Intel® Integrated Performance Primitives

problems with ippiMalloc_8u_C4()

Andres,