Re: Problem with heap and malloc()/free()
Zapanaz schrieb:
I have a program which has been having a number of problems with heap
memory ... this is built in MSVC++ 6.0, recently I added support for
unicode, and switched from static link libraries to DLLs for LGPL
reasons.
The current problem, I have class StringHandler, which has a public
member
wchar_t * wc;
In my application class, I call a method of StringHandler which
assigns a string to this pointer,
wc = (wchar_t *)malloc(requiredBytes);
int error = MultiByteToWideChar(CP_UTF8, 0, kpcIn, -1, wc,
requiredBytes);
Read the documentation about MultiByteToWideChar, it says about cchWideChar:
cchWideChar
[in] Size, in WCHAR values, of the buffer ...
You are allocating requiredBytes BYTES, but tell MultiByteToWideChar that the
buffer is requiredBytes WCHARs long. So you create a buffer overrun.
You did not show where does requiredBytes comes from. If it really contains the
number of bytes, then you need to call
int error = MultiByteToWideChar(
CP_UTF8, 0, kpcIn, -1, wc, requiredBytes/sizeof(WCHAR));
If it contains the number of charcters, then you need to allocate
wc = (wchar_t *)malloc(requiredBytes * sizeof(WCHAR));
or much clearer IMHO:
wc = new wchar_t[requiredBytes];
(if course you would use delete[] wc instead of free(wc) to free the buffer.
Norbert
Then in the destructor for StringHandler, I try to free this memory
free(wc);
And I get an ASSERT on this function
CrtIsValidHeapPointer()
Just for the heck of it I tried this in the destructor
void * test = malloc(1000);
free(test);
And that works fine, no ASSERT.
Searching for similar problems on Google, I found a number of similar
cases. In all cases, it seemed to involve memory allocated by a DLL,
then freed by the calling program.
I am using two DLL's in the program (one for expat, an XML parser, and
one for id3lib, an MP3 tag reader) but neither of them have been
called at this point in the program (note expat also has a static link
.lib which you have to link against, even if you are using the DLL).
I also have the project set to "Use MFC in a shared DLL".
So I am wondering:
- Can this be getting caused by the DLL's, even though they haven't
been called yet? Some of the similar problems I found on Google
talked about using DLL's which had been built on different settings
(I'm definitely using the debug versions of the DLL's and the .lib,
but I haven't checked thoroughly into all their settings in detail),
and used different calling conventions than the main program. Is it
possible that, even though they haven't been called by my code, that
they are creating some kind of inconsistency in my code's calling
conventions that is leading to the the heap error?
- Is it possible that it has something to do with the MFC dll's
themselves? That doesn't seem to make sense, because if they are
doing anything it's just the malloc itself, I'm not sure how I can
differentiate between DLL allocated memory and "correct" heap pointers
if that's the case.
- Should I be looking at other project settings and I'm on the wrong
track completely as far as the DLL's?
Thanks for any ideas ...