10

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.

Mark Rotteveel
  • 100,966
  • 191
  • 140
  • 197
Gabriel Devillers
  • 3,155
  • 2
  • 30
  • 53
  • Your solution #2 is no solution at all. There is no single binary-compatible definition of `shared_ptr`. – Ben Voigt Oct 06 '22 at 14:59
  • Yes, I know that there are 2 importants points to take into account at DLL boundaries: ABI compatibility and "heap sharing safety". My understanding is that having "heap sharing safety" implies having ABI compatibility, but that the reciprocal is false, do you confirm ? – Gabriel Devillers Oct 06 '22 at 15:15
  • 2
    No not at all, you've missed adherence to the One Definition Rule. You can have two C++ compilers sharing the same allocator (perhaps provided by the C library) but with incompatible C++ standard library. Even worse, `std::shared_ptr` is not a standard-layout class, so different C++ compilers seeing the same header file can produce different binary layouts. – Ben Voigt Oct 06 '22 at 15:21

1 Answers1

8

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.

MSalters
  • 173,980
  • 10
  • 155
  • 350