title: Memory allocation and deallocation across dll boundaries
body: <p>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:</p>
  
  <pre><code>typedef std::vector &lt; SessionFields, 
          OurAllocator &lt; SessionFields &gt; &gt; 
          VectorSessionFields;
  
  typedef std::set &lt; SessionFields, 
          std::less &lt; SessionFields &gt;, 
          OurAllocator &lt; SessionFields &gt; &gt; 
          SetSessionFields;
  </code></pre>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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 (<em>although this does sound very messy</em>).</p>
  
  <p>Alternatively, I'm also looking at using <code>GetProcessHeaps</code> to identify the heap used from within the SDK, and try to free against this heap, instead of the default heap.</p>
  
  <p>Has anyone any advice on how we can solve this problem?</p>