C++ Memory leak when freeing *? - c++

Question

I am using this in a void:
unsigned char *nEncodedBytes = NULL;
nEncodedBytes = new unsigned char[m_lLenCompressedBytes];
short *shrtDecoded = NULL;
shrtDecoded = new short[iCountDecodedShorts];
short *m_ShortOut;
m_ShortOut = (short*)malloc(( 960*6)*sizeof(short));
unsigned char *m_DataBytes;
m_DataBytes = (unsigned char*)calloc((960*6),sizeof(char));
When I am done, I free the memory using
delete (nEncodedBytes);
delete (shrtDecoded);
free(m_DataBytes);
free(m_ShortOut);
Is this fine? I am unsure why I was using delete in one place, and free in the other.
I copied my code around.
Is there a memory leak?
Thank you.

Answer 1

You use free when you use malloc. In all likelihood, you shouldn't be using malloc at all in C++; it's the C way of doing things and only rarely wanted in C++.
You use delete when you allocate with new. new calls the constructor as well as allocating memory, and delete calls the destructor as well as releasing memory. These are thus the object orientated C++ options. There is, however, a wrinkle. Because the implementation of C++ doesn't know whether a pointer refers to an array or a single object if you allocate an array (e.g. nEncodedBytes = new unsigned char[m_lLenCompressedBytes];) then you should use delete[] instead of delete to release it.
Mind you, failing to call delete[] only means that you will only call the destructor for the first object in an array so, in this particular case there should be no difference in the outcome between calling delete[] and calling delete because char has no destructor.
I don't see a memory leak in your code but since you haven't posted all your code we can't tell.

Answer 2

You should use
delete [] nEncodedBytes;
delete [] shrtDecoded;
as you are deleting arrays.

Answer 3

Don't mix malloc and new (first because of stylistic reasons, and then because you should never delete a  malloc-ed memory or free a new-ed zone). Consider using standard C++ containers. You won't even need to explicitly allocate memory (the library will do that for you).
You could code
std::vector<char> nEncodedBytes;
nEncodedBytes.resize(encodedbyteslen);
On Linux, use valgrind to hunt memory leaks. BTW, you might be interested by Boehm's GC, perhaps using its allocator like here.
BTW, when using yourself malloc you should always test its result, at least like
SomeType* ptr = malloc(sizeof(SomeType));
if (!ptr) { perror("malloc SomeType"); exit(EXIT_FAILURE); };
remember that malloc could fail. You may want to limit the memory available (e.g. with ulimit -m in bash in your terminal) for testing purposes (e.g. to make malloc -or new- fail more easily to ensure you handle that kind of failure well enough).

Answer 4

Is this fine?
Not quite. There are a couple problems. One -- your troublesome use of free -- we'll address in a moment. But first, your use of new[] with delete (non-[]) invokes Undefined Behavior:
Here you are using new []:
nEncodedBytes = new unsigned char[m_lLenCompressedBytes];
And here you are using delete:
delete (nEncodedBytes);
This should be:
delete [] nEncodedBytes;
Using the [] for of new with the non-[] form of delete invokes Undefined Behavior. Now in reality, all the compilers & platforms I'm aware of will handle this fine and do what you expect in this particular case -- but you should never rely on Undefined Behavior.
Now for your use of malloc and free:
I am unsure why I was using delete in one place, and free in the
other.
You probably shouldn't be. Here's a rule of thumb:
In C++, always use new and delete; never use malloc and free.
Yes, there are exceptions, but they are first of all rare, and second of all you will know exactly when the exceptions come in to play. In the example you've posted here, I see no reason that compels the use of malloc and free. Hence, you should not be.
Contrary to (popular?) belief, mixing new/delete and malloc/free in a single C++ program does no in itself invoke Undefined Behavior or make your program otherwise ill-formed. You can do it, if you do it properly. But you still shouldn't.
Is there a memory leak?
Well, since you have invoked Undefined Behavior, there could be. Undefined Behavior means anything can happen. You are however de-allocating everything you allocate in the code shown. So aside from the UB, I see no memory leak here.