_CrtIsValidHeapPointer and templates

  • Thread starter Thread starter =?iso-8859-1?q?Erik_Wikstr=F6m?=
  • Start date Start date
?

=?iso-8859-1?q?Erik_Wikstr=F6m?=

I have a native DLL which is called from a managed application. One of
the calls to the DLL returns a std::vector<Cell> (by value) where
Cell is a POD type, everything works fine until the function making
the call to the DLL returns, at which point I get a
CrtIsValidHeapPointer assertion failure.

As I understand things this is because the Cell-objects in the
std::vector are allocated on the DLL's heap but when the function
returns in the managed application (and the automatic variable goes
out of scope) and the std::vector's destructor is called it is
"working" on the managed heap.

Is there a way to solve this without having to rewrite the DLL, I
would prefer not to return a pointer to the std::vector<Cell> since it
(currently) is created on the fly from a much larger, internal,
structure.
 
I have a native DLL which is called from a managed application. One of
the calls to the DLL returns a std::vector<Cell> (by value) where
Cell is a POD type, everything works fine until the function making
the call to the DLL returns, at which point I get a
CrtIsValidHeapPointer assertion failure.

As I understand things this is because the Cell-objects in the
std::vector are allocated on the DLL's heap but when the function
returns in the managed application (and the automatic variable goes
out of scope) and the std::vector's destructor is called it is
"working" on the managed heap.
Click to expand...

Erik,

Ensure that the DLL and the EXE are both built with the same version
of VS and that they both use the DLL version of the 'C' run-time
library - that way they'll use a common native heap. Also - don't mix
debug/release modules.

Dave
 
(sorry for top-post, OE yet again fails to quote)
native types, such as std::vector, are never instantiated on the managed
heap.

When you say that Cell is a POD type, I assume it is declared as a native
struct in both the application and the DLL?



I have a native DLL which is called from a managed application. One of
the calls to the DLL returns a std::vector<Cell> (by value) where
Cell is a POD type, everything works fine until the function making
the call to the DLL returns, at which point I get a
CrtIsValidHeapPointer assertion failure.

As I understand things this is because the Cell-objects in the
std::vector are allocated on the DLL's heap but when the function
returns in the managed application (and the automatic variable goes
out of scope) and the std::vector's destructor is called it is
"working" on the managed heap.

Is there a way to solve this without having to rewrite the DLL, I
would prefer not to return a pointer to the std::vector<Cell> since it
(currently) is created on the fly from a much larger, internal,
structure.
 
(sorry for top-post, OE yet again fails to quote)
Fixed

native types, such as std::vector, are never instantiated on the managed
heap.

When you say that Cell is a POD type, I assume it is declared as a native
struct in both the application and the DLL?
Click to expand...

Yes, it's declared in a headerfile in the DLL-project which is also
included in the EXE-project.

To David Lowndes:
They are both part of the same solution in Visual C++, and if that
does not give the right versions then I don't know how.
 
Erik said:
To David Lowndes:
They are both part of the same solution in Visual C++, and if that
does not give the right versions then I don't know how.
Click to expand...

You set the CRT version in the project properties->C/C++->Code
Generation->Runtime Library. Both modules have to use a DLL version of
the CRT, and both have to use the same one, to ensure that they share
their heap.

Tom
 
You set the CRT version in the project properties->C/C++->Code
Generation->Runtime Library. Both modules have to use a DLL version of
the CRT, and both have to use the same one, to ensure that they share
their heap.
Click to expand...

Ah, that's the problem. For some reason I have set the DLL to be
statically linked to the CRT (don't know why) and I was sure I hadn't
changed that.

Thank you al for your help.
 
I have a native DLL which is called from a managed application. One of
the calls to the DLL returns a std::vector<Cell> (by value) where
Cell is a POD type, everything works fine until the function making
the call to the DLL returns, at which point I get a
CrtIsValidHeapPointer assertion failure.

As I understand things this is because the Cell-objects in the
std::vector are allocated on the DLL's heap but when the function
returns in the managed application (and the automatic variable goes
out of scope) and the std::vector's destructor is called it is
"working" on the managed heap.

Is there a way to solve this without having to rewrite the DLL, I
would prefer not to return a pointer to the std::vector<Cell> since it
(currently) is created on the fly from a much larger, internal,
structure.
Click to expand...
This is a bit late, since you don't want to change the dll. But for what
it's worth, the other suggestions in this thread about matching runtimes
will work but I consider them risky and too easy to break with future
development.

My own approach is that whenever a dll has to allocate memory it gets
passed in an allocator function that allocates in the caller heap. I
will frequently use CoGetMalloc for this.

This way, no matter how the run times shake our, you still have
consistant allocation.

++PLS
 
Back
Top