Re: Memory corruption of DLL class object
On Fri, 20 Feb 2009 12:11:01 -0800, BoHuang
<BoHuang@discussions.microsoft.com> wrote:
I started to use Nvidia's nvImage library (nvImage.dll) for loading images.
It has been around for years.
But even at my program entry point, which I would assume has not been tinted
with possible mem leaks/corruptions in my app later on, I am seeing this:
BOOL myMFCApp::InitInstance()
{
nv::Image* pImg = new nv::Image();
//app breaks here with message "This may be due to a corruption on the heap"
//specifically, the call stack breaks at
//'retval = HeapFree(_crtheap,0,pBlock)' in free.c
delete pImg;
//Or alternatively, this triggers stack corruption too at end of this block
{
nv::Image img;
}
//rest of my init
}
More interestingly, my laptop (Vista Ultimate) and desktop (Vista Business),
using both MSVC 9.0.21022.8 RTM, I get different behaviors:
Desktop:
Does not break or yield any error for the stack allocated example.
Laptop:
Breaks for both stack and heap examples. Moreover, a member std::vector in
nv::Image has a seven figure size instead of zero.
I don't think Nvidia's library has problems. I have the source and even
recompiled the DLL to explicitly clear the std::vector but still the huge
size and memory corruption occurs in my MFC App.
I have to note that as long as I don't delete the nv::Image objects, I can
use all its functionalities and my app runs fine.
How would I know if I am linking/using the DLL properly?
It sounds like you will need to link the DLL and everyone who uses it to
the same CRT DLL. This means matching debug and release versions as well as
version numbers. You can use tools such as Dependency Walker and Process
Explorer to determine if you have multiple CRT DLLs loaded. Furthermore,
you can use depends to determine if a module does not load a CRT DLL, which
can also be an error, since multiple copies of the static CRT or a mix of
static and dynamic CRTs are not compatible with sharing C++ objects across
module boundaries.
Note that even though you are creating and deleting the nv::Image object in
the same module, depending on how it is written, you may be creating and
deleting its std::vector data in different module contexts. This could
cause heap corruption as a different heap is used to free the object's data
than was used to allocate it.
--
Doug Harrison
Visual C++ MVP