Bug Report: memory leak in shrSavePPM4ub Found a memory leak in the function shrSavePPM4ub in ShrUti

Accelerated Computing CUDA CUDA Programming and Performance
#1

In a shared utility library called shrUtils.h there is a major memory leak in the function shrSavePPM4ub()

This function strips the four channel of the passed image data before calling savePPM(). To do this, it allocates a new buffer of size w * h * 3 bytes which is never freed.

////////////////////////////////////////////////////////////////////////////////

//! Save PPM image file (with unsigned char as data element type, padded to 4 byte)

//! @return shrTrue if reading the file succeeded, otherwise shrFALSE

//! @param file  name of the image file

//! @param data  handle to the data read

//! @param w	 width of the image

//! @param h	 height of the image

////////////////////////////////////////////////////////////////////////////////

shrBOOL shrSavePPM4ub( const char* file, unsigned char *data, unsigned int w, unsigned int h) 

{

	// strip 4th component

	int size = w * h;

	unsigned char *ndata = (unsigned char*) malloc( sizeof(unsigned char) * size*3);

	unsigned char *ptr = ndata;

	for(int i=0; i<size; i++) {

		*ptr++ = *data++;

		*ptr++ = *data++;

		*ptr++ = *data++;

		data++;

	}

	

	return savePPM(file, ndata, w, h, 3);

}

Sorry if this is a known issue, I couldn’t find anything on the forums about it. I suppose its not a popular method. It’s easily fixed by changing the return line:

shrBOOL succ = savePPM(file, ndata, w, h, 3);

free(ndata);

return succ;
#2

There’s also a Memory Leak in shrComparePPM(), another function in shrUtils.h

Both ref_data and src_data are never deallocated. In fact, they’re never initialized to NULL, which results in an error in loadPPM().

#3

Also some SDK samples have memory leaks. Someone please wake the interns @ nVidia… ;)

#4

Thanks for the bug report, fixed. Which other SDK samples have leaks?

The offending intern has been suitably punished :)

#5

let me refer you to this thread. I haven’t verified the 3.1 beta SDK yet.

http://forums.nvidia.com/index.php?showtop…80#entry1044128

#6

Glad to hear I’m being helpful! I also just noticed another memory leak in the same library, not sure if its fixed yet in the most recent source but it still appears in OpenCL examples on the site.

// Optional LogFileName Override function

// ************************************************************

*********

char* cLogFilePathAndName = NULL;

void shrSetLogFileName (const char* cOverRideName)

{

	if( cLogFilePathAndName != NULL ) {

		free(cLogFilePathAndName);

	}

	cLogFilePathAndName = (char*) malloc(strlen(cOverRideName) + 1);

	#ifdef WIN32

		strcpy_s(cLogFilePathAndName, strlen(cOverRideName) + 1, cOverRideName);

	#else

		strcpy(cLogFilePathAndName, cOverRideName);

	#endif

	return;

}

No cleanup functions seem to exist to free the cLogFilePathAndName pointer allocated in this method.