Heap corruption when using DLL code

Question

I have some code that I need to place in a common library dll. This code, a class CalibrationFileData, works perfectly fine when it's built as part of the current project. However, if CalibrationFileData is built in the common library, the program crashes, mentioning heap corruptions.

I have made sure that all allocations and deallocations occur within the class, with appropriate accessors, etc. Still, the problem won't go away. Just in case it makes any difference, I am sometimes passing vectors of pairs, definitely not plain old data, but the vector manipulation only occurs through the accessors, so there shouldn't be any allocation happening across modules.

Anything I'm missing?

Edit: The vectors are these:

std::vector<std::pair<CvPoint2D32f, CvPoint3D32f>>* extrinsicCorrespondences;
std::vector<int>* pointsPerImage;

I shouldn't need to worry about deep copies, since they're not heap allocated, right? Incidentally, I tried using pointers to vectors, as above, to sidestep the problem, but it didn't make a difference anyway.

Answer 1

You should distinguish between tightly coupled and loosely coupled DLLs.

Tightly coupled DLLs mean that

the DLL is built with the exact same compiler version, packing and calling convention settings, library options as the application, and both dynamically link to the runtime library (/MD compiler option). This lets you pass objects back and forth including STL containers, allocate DLL objects from inside the application, derive from base classes in the other module, do just about everything you could without using DLLs. The disadvantage is that you can no longer deploy the DLL independently of the main application. Both must be built together. The DLL is just to improve your process startup time and working set, because the application can start running before loading the DLL (using the /delayload linker option). Build times are also faster than a single module, especially when whole program optimization is used. But optimization doesn't take place across the application-DLL boundary. And any non-trivial change will still require rebuilding both.

In case of loosely coupled DLLs, then

When exporting DLL functions, it's best if they accept only integral data types, i.e. int or pointers.

With reference, for example, to strings, then:

When you need to pass a string, pass it as a const char *. When you need the DLL function to return a string, pass to the DLL a char * pointer to a pre-allocated buffer, where the DLL would write the string.

Finally, concerning memory allocation, then:

Never use memory allocated by the DLL outside of the DLL's own functions, and never pass by value structures that have their own constructor/destructor.

References

Heap corruption when returning from function inside a dll

Can I pass std::string to a DLL?

Answer 2

In the command line option, in visual studio remove this _SECURE_SCL. Mostly this crash is caused by _SECURE_SCL mismatch among the details. More details can be found here: http://kmdarshan.com/blog/?p=3830

Answer 3

Check the compile flags match between the library and the executable. For example, on Windows ensure you're using the same C Runtime Library (CRT) (/MD vs /MT). Check for warnings from the linker.

Answer 4

It's likely you missed some piece of the client's code that tries to deallocate a memory that your DLL allocated or vice versa.

Perhaps the easiest thing to do would be to ensure that both client and the DLL use the same memory allocator. Not just the same kind, but the same actual "instance" of the allocator. On Visual C++, this is most easily achieved by both client and DLL using a "Multi-threaded Debug DLL (/MDd)" or "Multi-threaded DLL (/MD)" runtime library.

Answer 5

Could it be different values defined for _SECURE_SCL in the two projects ?

Answer 6

you should check deep copies inside vector object,it is pertain with deepcopy i think

Answer 7

Are you certain that when you take ownership of the contents of the vector objects, within your methods, you are deep-copying them into your instance variables?