Re: heap shared with DLL

Michael,

Thanks for reply.

Reading your explanation, it looks like the code sample should be valid for
existing CRT implementations. I've seen that new/delete are implemented in
coredll.dll. As long I dont have another implementation (i.e. statically
linked) it should be impossible to mix debug and release CRT because they
share this coredll.dll.

But we have seen a lot of trouble, when were working at WinXP with DLLs
using differen MFC versions (VC 6.0, VS2003). It looks like theese MFC
versions used there own allocators.

Do you know, if the WinCE MFC (mfcce300.dll, mfcce400.dll, mfc80u.dll) has
own allocator?


/Helge


"Michael Salamone" <mikesa#at#entrek#dot#com> wrote in message
news:E63F030D-9F08-48EF-B687-EC981716FF2C@xxxxxxxxxxxxxxxx
Hi Helge,

This has never been true for WinNT/2K/XP, and never true for WinCE. I
can't imagine this was true in Win95 either, but perhaps it was and
perhaps that's what the author was referring to?

In any case, in WinNT/2K/XP and in WinCE heaps are process-owned, and the
heap manger (not the EXE or DLL) maintains alloc/free states of blocks.

In Win32, heaps are identified by heap handle (returned from HeapCreate).
Calls to HeapAlloc(hHeap, ...) and then HeapFree(hHeap, ...) is fine
across modules. LocalAlloc/LocalFree just resolve to
HeapAlloc(GetProcessHeap(),...) and HeapFree(GetProcessHeap()).

In early WinCE MS CRT lib (incl new/delete), these were straight calls to
LocalAlloc/LocalFree, so worked off the main process heap. Though it's a
very bad idea, you could actually new/LocalReAlloc/free or
new/realloc/LocalFree and all would be fine. In MS desktop CRT (and maybe
even newer WinCE - haven't checked recently), it creates a heap internally
for malloc/free - and maybe still another for new/delete, so mixing is
going to be a problem. And since it's a very bad idea, you just don't do
that anyway (though I have seen code that does!).

You can get into trouble if you mix allocators from one runtime with
deallocators from another runtime. Let's say your EXE is linked to MS CRT
and your DLL is linked to 3rd party CRT. Calling new in EXE and delete in
DLL is going to be a disaster. Same could be true (but less likely) if
you link to debug CRT in one module and release CRT in another module.

With COM as the article is referring to, you typically use
CoTaskMemAlloc/CoTaskMemRealloc/CoTaskMemFree. You could pass these
pointers safely around your own app (exe/dll) as well as back to VB and
CLR (if using COM Interop and your idl is correct).

Michael Salamone, eMVP
Entrek Software, Inc.
www.entrek.com


"Helge Kruse" <Helge.Kruse-nospam@xxxxxxx> wrote in message
news:uQk$f8BpHHA.2596@xxxxxxxxxxxxxxxxxxxxxxx
Hello,

in article http://msdn2.microsoft.com/en-us/library/ms809983.aspx you can
read in section "Memory Allocation", that DLLs have an own heap and
objects created in a DLL must be released in that DLL to avoid heap
corruption.

How is this related to Windows CE? Are there differences in the Windows
CE version 3.0, 5.0, 6.0?

I have a 3rd party class library (DLL) with this exported function:

void CFoo::Calculate(PBYTE& pData, int& nSize)
{
if (nSize < SIZE_NEEDED)
{
delete pData;
pData = new BYTE[SIZE_NEEDED];
nSize = SIZE_NEEDED;
}
memcpy(pData, USEFUL_DATA, SIZE_NEEDED);
}

Since the caller in the EXE module or another DLL had allocated some
bytes, passed with pData, on the callers heap, this should be a problem
in Win32.

Will we get in trouble, when the pData is deleted in the caller DLL or
the EXE module?


/Helge


--
Time is an ocean but it ends at the shore




.

Relevant Pages

  • Re: heap shared with DLL
    ... In any case, in WinNT/2K/XP and in WinCE heaps are process-owned, and the heap manger (not the EXE or DLL) maintains alloc/free states of blocks. ... In MS desktop CRT, it creates a heap internally for malloc/free - and maybe still another for new/delete, so mixing is going to be a problem. ...
    (microsoft.public.windowsce.embedded)
  • Re: DLL pass vector by value crash
    ... I can't see why the issue of common heap and allocator (operator ... Presuming that you build your exe and dll with same compiler and same ... allocation functions are called, ...
    (microsoft.public.vc.mfc)
  • Re: DLL pass vector by value crash
    ... stack of the exe and may allocate default member element on the exe heap. ... If this is a dangerous situation, the simple app I set up calling testFunc() ... in a dll did not crash. ...
    (microsoft.public.vc.mfc)
  • Re: CoCreateInstance Crash
    ... CoTaskMemAlloc/Free do not use the same heap as the CRT. ... OLE DLL loads. ... >> to allocate memory for return arguments via CoTaskMemAlloc ...
    (microsoft.public.vc.atl)
  • Re: Internal of C/C++ run time library (Module offers a function that allocates memory, must also o
    ... Note that _heap_init() creates a heap using HeapCreate, ... A trivial experiment with a statically-linked CRT in a DLL demonstrates that an attempt to ... Some of these modules can link to a static version of the C/C+ ...
    (microsoft.public.vc.mfc)
Loading