CODEWITHSUNDEEP
c++memory-managementdllshared-librariesheap-memory
Gabriel Devillers
Gabriel Devillers

Reputation: 4012

C++ test if two DLLs share the same heap

It is well known that the freeing of heap memory must be done with the same allocator as the one used to allocate it. This is something to take into account when exchanging heap allocated objects across DLL boundaries.

One solution is to provide a destructor for each object, like in a C API: if a DLL allows creating object A it will have to provide a function A_free or something similar 1.

Another related solution is to wrap all allocations into shared_ptr because they store a link to the deallocator 2.

Another solution is to "inject" a top-level allocator into all loaded DLLs (recursively) 3.

Another solution is to just to not exchange heap allocated objects but instead use some kind of protocol 4.

Yet another solution is to be absolutely sure that the DLLs will share the same heap, which should (will?) happen if they share compatible compilations options (compiler, flags, runtime, etc.) 5 6. This seems quite difficult to guarantee, especially if one would like to use a package manager and not build everything at once.

Is there a way to check at runtime that the heaps are actually the same between multiple DLLs, preferably in a cross-platform way?

For reliability and ease of debugging this seems better than hoping that the application will immediately crash and not corrupt stuff silently.

Upvotes: 10

Views: 406

Answers (1)

MSalters
MSalters

Reputation: 179961

I think the biggest problem here is your definition of "heap". That assumes there is a unique definition.

The problem is that Windows has HeapAlloc, while C++ typically uses "heap" as the memory allocated by ::operator new. These two can be the same, distinct, a subset, or partially overlapping.

With two DLL's, both might be written in C++ and use ::operator new, but they both could have linked their own unique versions. So there might be multiple answers to the observation in the previous paragraph.

Now let's assume for an example that one DLL has ::operator new forward directly to HeapAlloc, but the other counts allocations before calling HeapAlloc. Clearly the two can't be mixed formally, because the count kept by the second allocator would be wrong. But the code is so simple that both news are probably inlined. So at assembly level you just have calls to HeapAlloc.

There's no way you can detect this at runtime, even if you would disassemble the code on the fly (!) - the inlined counter increment instruction is not distinguishable from the surrounding code.

Upvotes: 8

Related Questions