Re: Avoiding heap corruption in debug build
On Dec 7, 9:42 pm, Woody <ols6...@sbcglobal.net> wrote:
When I run my app, I am getting a message "Invalid address specified
to RtlValidateHeap / This may be due to a corruption of the heap...".
This is an MFC dialog-based static build, using VS2005/XP.
Using the debugger, I have isolated the error to the code in my app
mp_real sqrt2;
std::string s
s=sqrt2.to_string(50);
The error message comes from the destruction of the temporary string
returned by to_string; i e, when to_string returns, its result is in a
temporary string, which is copied to app's string s. The temporary
string provided by to_string is then destroyed.
'to_string' is a member function of the class mp_real, and its return
type is string.
string mp_real::to_string(...)
{
string s=...
return s;
}
This function is in a DLL, and I think the error message is occurring
because the DLL is linked to CRT and using its own heap. I have the
source and can build the DLL.
How should I do the build and link of the DLL and my app so a debug
version doesn't get this error? Also, I want to make sure that a
release build of the DLL will not have any similar problem? Can I use
a debug DLL with a release build of an app, or a release build of the
DLL with a debug build of an app?
Two modules (exe, dll) must link to the same version of C++ runtime
(that includes debug/release distinction, but also e.g. msvcpp90.dll
versus msvcpp71.dll). When you build your dll, make sure to have
different import lib name for each flavor. On top of that, if you want
to export a function that returns e.g. std::string, you can't use
static lib.
If you do not have a good match, you'll get all sorts of problems.
For example, with C malloc/free, and consequently operators new/
delete, if you allocate in one module, you can't deallocate in
another, because they may have two separate heaps and can't know how
to free stuff coming from another heap. Here's a test to check whether
your setup suffers from this problem: take the address of malloc when
inside exe code, and do the same when inside dll code. Chances are,
these don't match. Well, you can't do that. If module1 allocates
memory and gives it to module2, that another must use de-allocation
function from module1. Similar for e.g. fopen and other stuff. If you
e.g. use dynamic-link CRT, then both module1 and 2 use e.g. malloc/
free from CRT. But if they are built with different CRT versions, you
are in trouble - again.
In essence, all these problems stem from absence of any concept of
"modules" in C language. If you do have modules, you have no help from
compiler/linker, you have to make sure you're fine all by yourself.
Goran.