跨越dll边界的内存分配和释放 [英] Memory allocation and deallocation across dll boundaries

问题描述

我知道在一个dll中做内存分配，然后在另一个dll中释放可能会导致所有类型的问题，特别是关于CRT。这些问题在导出STL容器时尤其成问题。我们在编写与我们的库链接的自定义Adobe插件时遇到了这些问题，我们通过定义我们在所有容器中使用的自己的分配器来处理这些问题，例如：

I understand that memory allocations made in one dll then subsequently free'd in another can cause all sort of problems, especially regarding the CRT. These sorts of problems are especially problematic when it comes to exporting STL containers. We've experienced these sorts of problems before (when writing custom Adobe plugins that linked with our libraries) and we've worked round these issues by defining our own allocator that we use in all our containers, eg:

typedef std::vector < SessionFields, 
        OurAllocator < SessionFields > > 
        VectorSessionFields;

typedef std::set < SessionFields, 
        std::less < SessionFields >, 
        OurAllocator < SessionFields > > 
        SetSessionFields;

这在我们的代码中传递类型时效果很好，但是我们遇到了一个问题我们现在不得不在Adobe的SDK中调用一个函数，返回一个填充的向量，当它超出范围时会导致崩溃。

This has worked well when passing types to/from our code, however we've hit a problem in that we're now having to call a function in Adobe's SDK that returns a populated vector which causes a crash when it goes out of scope.

显然，这是一个问题内存分配在Adobe的SDK属于不同的堆，当它终于免费在我的代码。所以我认为也许我可以做一些聪明的方式，像某种程度上覆盖或导出在他们的SDK中使用的分配器，所以我可以使用它来清理从他们的函数返回的容器。

Obviously, it's a problem with memory being allocated in Adobe's SDK belonging to a different heap when it's finally free'd in my code. So I'm thinking that maybe I could do something clever like somehow overriding or exporting the allocator used in their SDK so I could use it to clean up containers returned from their functions.

我也在寻找一个包装或某种形式的thunking层，从而STL容器将安全编组在我的代码和SDK（虽然这听起来很乱} 。

I'm also looking at writing a wrapper or some sort of thunking layer whereby STL containers would be safely marshalled between my code and the SDK (although this does sound very messy).

或者，我也在使用 GetProcessHeaps 来标识从SDK中使用的堆，并尝试释放

Alternatively, I'm also looking at using GetProcessHeaps to identify the heap used from within the SDK, and try to free against this heap, instead of the default heap.

有没有任何人如何解决这个问题？

Has anyone any advice on how we can solve this problem?

推荐答案

足够讽刺的是，Adobe Source Libraries有一个 adobe :: capture_allocator 类是专门针对这种DLL安全性写的。它的工作方式是捕获局部 new 和 delete 在这一点上它被实例化，围绕着对象的生命周期。 （请参见 adobe :: new_delete_t 了解详情，尤其是实施这里。）使用捕获的 delete 例程进行解除分配，确保无论你在哪里删除 delete 。

Ironically enough, the Adobe Source Libraries has a adobe::capture_allocator class that was written specifically with this kind of DLL safety in mind. The way it works is to capture the local new and delete at this point it is instantiated, and to carry them both around for the lifetime of the object. (See adobe::new_delete_t for details on how it does this, especially the implementation here.) Deallocations take place with the captured delete routine, guaranteeing that no matter where you are you are deleting with the proper delete.

您可以看到 capture_allocator 整个 version_1 在Adobe Source Libraries中的类型，例如 adobe :: any_regular_t 和 adobe :: copy_on_write 。 capture_allocator 也应该与所有STL容器类型兼容。

You can see capture_allocator used throughout the version_1 types in the Adobe Source Libraries, such as adobe::any_regular_t and adobe::copy_on_write. capture_allocator should be compatible with all STL container types as well.

更新： capture_allocator 不符合标准，因为它保留状态。这不应该是它的可用性的一个大障碍，但它的确意味着它的使用不能保证使用符合标准的容器。

Update: capture_allocator is not standard-compliant because it retains state. This should not be a big hindrance to its usability, but it does mean its use is not guaranteed to work with standard-compliant containers.

这篇关于跨越dll边界的内存分配和释放的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！