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.

--
Erik Wikström

>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.

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?



"Erik Wikström" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
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.

--
Erik Wikström

On 17 Maj, 17:23, "Ben Voigt" <r...@nospam.nospam> wrote:
> "Erik Wikström" <eri...@student.chalmers.se> wrote in message
>>
>> news:(E-Mail Removed)...
>> 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?

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 Wikström

Erik Wikström wrote:

> 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.

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

On 18 Maj, 17:06, "Tom Widmer [VC++ MVP]" <tom_use...@hotmail.com>
wrote:
> Erik Wikström wrote:
> > 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.
>
> 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.

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.

--
Erik Wikström

In article <(E-Mail Removed)>,
(E-Mail Removed) says...
> 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.
>
> --
> Erik Wikström
>
>
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