title: Passing reference to STL vector over dll boundary
body: <p>I have a nice library for managing files that needs to return specific lists of strings. Since the only code I'm ever going to use it with is going to be C++ (and Java but that's using C++ through JNI) I decided to use vector from the standard libraries. The library functions look a little bit like this (where FILE_MANAGER_EXPORT is platform-defined export requirement):</p>
  
  <pre><code>extern "C" FILE_MANAGER_EXPORT void get_all_files(vector&lt;string&gt; &amp;files)
  {
      files.clear();
      for (vector&lt;file_struct&gt;::iterator i = file_structs.begin(); i != file_structs.end(); ++i)
      {
          files.push_back(i-&gt;full_path);
      }
  }
  </code></pre>
  
  <p>The reason I used the vector as a reference instead of return value is an attempt to keep memory allocations sane and because windows was really unhappy me having extern "C" around a c++ return type (who knows why, my understanding is that all extern "C" does is prevent name mangling in the compiler). Anyway, the code for using this with other c++ is generally as follows:</p>
  
  <pre><code>#if defined _WIN32
      #include &lt;Windows.h&gt;
      #define GET_METHOD GetProcAddress
      #define OPEN_LIBRARY(X) LoadLibrary((LPCSTR)X)
      #define LIBRARY_POINTER_TYPE HMODULE
      #define CLOSE_LIBRARY FreeLibrary
  #else
      #include &lt;dlfcn.h&gt;
      #define GET_METHOD dlsym
      #define OPEN_LIBRARY(X) dlopen(X, RTLD_NOW)
      #define LIBRARY_POINTER_TYPE void*
      #define CLOSE_LIBRARY dlclose
  #endif
  
  typedef void (*GetAllFilesType)(vector&lt;string&gt; &amp;files);
  
  int main(int argc, char **argv)
  {
      LIBRARY_POINTER_TYPE manager = LOAD_LIBRARY("library.dll"); //Just an example, actual name is platform-defined too
      GetAllFilesType get_all_files_pointer = (GetAllFilesType) GET_METHOD(manager, "get_all_files");
      vector&lt;string&gt; files;
      (*get_all_files_pointer)(files);
  
      // ... Do something with files ...
  
      return 0;
  }
  </code></pre>
  
  <p>The library is compiled through cmake using add_library(file_manager SHARED file_manager.cpp). The program is compiled in a separate cmake project using add_executable(file_manager_command_wrapper command_wrapper.cpp). There are no compile flags specified for either, just those commands.</p>
  
  <p>Now the program works perfectly fine in both mac and linux. The problem is windows. When run, I get this error:</p>
  
  <blockquote>
    <p>Debug Assertion Failed!</p>
    
    <p>...</p>
    
    <p>Expression: _pFirstBlock == _pHead</p>
  </blockquote>
  
  <p>This, I have found out and kind of understand, is because of separate memory heaps between executables and loaded dlls. I believe this occurs when memory is allocated in one heap and deallocated in the other. The problem is, for the life of me, I can't figure what is going wrong. The memory is allocated in the executable and passed as a reference to the dll function, values are added via the reference, and then those are processed and finally deallocated back in the executable.</p>
  
  <p>I would reveal more code if I could but intellectual property at my company states I can't, so all of the above code is merely examples.</p>
  
  <p>Anyone with more knowledge of the subject able to help me understand this error, and point me in the right direction to debug and fix it? I'm unfortunately not able to use a windows machine for debugging since I develop on linux, then commit any changes to a gerrit server which triggers builds and tests through jenkins. I have access to the output console upon compile and test.</p>
  
  <p>I did consider using non-stl types, copying the vector in c++ to a char**, but the memory allocation was a nightmare and I was struggling to get it working nicely on linux let  alone windows and it's horrible multiple heaps.</p>
  
  <p>EDIT: It definitely crashes as soon as the files vector goes out of scope. My current thought is that the strings put into the vector are allocated on the dll heap and deallocated on the executable heap. If this is the case, can anyone enlighten me as to a better solution?</p>