_CrtIsValidHeapPointer and templates

Discussion in 'Microsoft VC .NET' started by =?iso-8859-1?q?Erik_Wikstr=F6m?=, May 16, 2007.

  1. 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
     
    =?iso-8859-1?q?Erik_Wikstr=F6m?=, May 16, 2007
    #1
    1. Advertisements

  2. >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
     
    David Lowndes, May 16, 2007
    #2
    1. Advertisements

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

    Ben Voigt Guest

    (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" <> wrote in message
    news:...
    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
     
    Ben Voigt, May 17, 2007
    #3
  4. On 17 Maj, 17:23, "Ben Voigt" <> wrote:
    > "Erik Wikström" <> wrote in message
    >>
    >> news:...
    >> 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
     
    =?iso-8859-1?q?Erik_Wikstr=F6m?=, May 18, 2007
    #4
  5. 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
     
    Tom Widmer [VC++ MVP], May 18, 2007
    #5
  6. On 18 Maj, 17:06, "Tom Widmer [VC++ MVP]" <>
    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
     
    =?iso-8859-1?q?Erik_Wikstr=F6m?=, May 21, 2007
    #6
  7. =?iso-8859-1?q?Erik_Wikstr=F6m?=

    PLS Guest

    In article <>,
    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
     
    PLS, May 24, 2007
    #7
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Raven
    Replies:
    0
    Views:
    1,391
    Raven
    May 2, 2004
  2. Adriano Coser

    _CrtIsValidHeapPointer exception

    Adriano Coser, Mar 31, 2005, in forum: Microsoft VC .NET
    Replies:
    4
    Views:
    4,307
    john_1726
    Jul 31, 2007
  3. jiing
    Replies:
    0
    Views:
    2,495
    jiing
    Apr 30, 2005
  4. jiing

    _CrtIsValidHeapPointer(pUserData) in dbghelp.c

    jiing, Apr 30, 2005, in forum: Microsoft VC .NET
    Replies:
    4
    Views:
    3,980
    Rani Manickam
    May 3, 2012
  5. Guest

    _CrtIsValidHeapPointer

    Guest, May 24, 2007, in forum: Microsoft VC .NET
    Replies:
    3
    Views:
    873
    SvenC
    May 24, 2007
Loading...

Share This Page