1

I have a strange problem where I suffer from crashes when deleting objects in my code. The objects are valid, there are no memory leaks that could overwrite them and it happens only in debug mode. The same code compiled with Linux works fine in both, debug and release builds. So I'd guess it is some strange problem with the Visual Studio debug-CRTs.

My software is structured as follows:

Two static libraries are compiled in mode "Multi threaded (debug) DLL" and are linked with: A shared library (DLL) that is compiled in mode "Multi threaded (debug)". From logic I'd say it should be the other way round but then I get HUGE amounts of unresolved symbols.

Finally there is an executable that is compiled in mode "Multi threaded (debug) DLL" which calls the DLL mentioned above. Here it does not make a difference when I switch to "Multi threaded (debug)".

The crash on object deletion happens in dbgheap.c / _heap_alloc_dbg_impl() -> mlock.c / _unlock() - a function of

So: what could be the problem? Is it really some CRT-incompatibility in debug mode or what else could be the reason? I'm quite sure that it is not a typical memory leak since it works smoothly with Linux and in release build.

Elmi
  • 5,899
  • 15
  • 72
  • 143
  • Change your shared library (DLL) compilation settings to "Multi-threaded Debug DLL" (/MDd compiler switch). The CRT settings must be the same for each one of your libraries and .EXE. – Mr.C64 Apr 11 '13 at 09:55

1 Answers1

1

When you statically-link libraries, you must pay attention that you use the same CRT "flavors".

When you use DLLs:

  • if they expose a pure-C interface (e.g. there are no STL classes at the boundaries) and you make sure that memory allocations and deallocations are both done inside the library code (or, more generally, both client and library use the same allocator)

  • or if they are COM DLLs

then you can use them from executables built with different flavors of CRTs, or even built with different versions of the VC++ compiler.

But if your DLLs have C++ classes (like STL classes) at the boundaries, then there are strong restrictions as for static-linking libraries, i.e. you have to use the same CRT flavors (debug or release) dynamically linked for the DLLs and the EXE, and both EXE and DLLs must be built with the same compiler and same settings (like _HAS_ITERATOR_DEBUGGING).

Mr.C64
  • 41,637
  • 14
  • 86
  • 162