- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page