Dll & Vectors

[Bernhard]

I have got the following situation (VC6) i have got two dll's each exporting functions like this void fun1 (std::vector& vec); The calling function passes an empty vector.. it is filled in the dll.. and the dll passes the filled vector back. One dll works perfectly fine. The other dll has got the following problem: After leaving the function which called the dll - function (when the passed vector leaves the scope) there is a runtime bug, which says that a debug assertation failed.. and that the following expression failed: _CrtIsValidHeapPointer(pUserData) One the one hand i do understand, why this could be (allocating memory in another process and freeing it in the other).. but WHY does this technique work happily with one dll, and why not with the other dll ? Any ideas ? Thanks in advance, bernhard

---

"Just looking for loopholes." W. C. Fields
American actor, 1880-1946, explaining why he was reading the Bible on his deathbed.

[Anonymous]

link against the Multithreaded DLL Runtime Library.

[Mike Dimmick]

I suspect that one DLL is linked against the static version of the C run-time library, but the other, and the program, against the DLL version. The version that works is linked against the DLL; the one that doesn't is linked with a static version. Each time the C run-time is initialised (at program startup and at DLL initialisation, it creates a new operating system heap with HeapCreate. All allocations through the C run-time's allocation functions (malloc, ::operator new, calloc, realloc, etc) ultimately come from this heap using HeapAlloc/HeapRealloc - and all the deallocation functions pass this heap's handle to HeapFree. Aside: on NT 4 and older, and on Win9x systems, the CRT manages small blocks of memory from a single OS heap allocation because the OS heap wasn't very efficient with small blocks on those operating systems. This was improved with Windows 2000 and the CRT uses the OS heap directly for all allocations on these systems. If you're using the Debug version of the C run-time, when you free memory (which the destructor of vector does for you, using the allocator type parameter's deallocate function) the run-time checks that you passed a valid pointer using the _CrtIsValidHeapPointer function. It considers it invalid if HeapValidate returns FALSE, which will happen if the pointer came from a different heap. Since you're passing an empty vector into the function, an allocation happens within the DLL, from the heap used by that DLL. The DLL version of the CRT will set up a single heap shared by all binaries using the DLL version, but each binary linked to the static CRT will have its own heap. The vector (assuming it's a local variable in the calling function) is destroyed at the end of the calling function, so deallocate gets called, which uses ::operator delete against the heap used by the executable. This is the wrong heap, so you get the assertion. The fix is simple. All DLLs in the same process must link against the same C run-time DLL (a mixed process of some binaries linked with msvcrt.dll from VC 6 and some linked with msvcr70.dll or msvcr71.dll from VS.NET 2002 or 2003 will have similar problems). The alternative is to ensure that all allocations and deallocations happen within a particular DLL, and that objects never cross the bo

[Antony M Kancidrowski]

Also bear in mind the following KB article from MS. PRB: Access Violation When Accessing STL Object in DLL http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q172/3/96.asp&NoWebContent=1[^] Ant.