I have a DLL and 3 Applications which uses this DLL. (These application do not run simultaneously)
Out of 3 Applications, 2 work perfectly but 1 application doesn't get response from one DLL function after some time (at 7th function call, to be specific).
Also, The code works properly if I use debug version of Application OR my DLL. It stops in Release version only.
After spending 2 sleepless nights, I figured out that If I change project property of DLL from /MD to to /MT, this application works properly.
I have no clue why this thing is happening. Can anyone please explain this for the sake of a sleep deprived programmer!
Update:
I would be releasing this DLL in market and I can not say whether user application will be built is /MT or /MTD or whatever... Is there any way to make sure that it will work with any application.
In Windows speak, the EXE and DLL files are modules.
Each modules compiled dynamically (/MD) share one heap.
So in the dynamic modules, if one module calls malloc (or new)
and another module does the free (or delete) on the object all is good.
Each module compiled to link in the C runtime statically gets its own heap.
If one static module allocates an object and a different static or dynamic
module tries to free the object, the program will crash because the allocate
and free are against different heaps.
Allocating and freeing memory across module boundaries
/MD links the runtime as dynamic, if the computer you have a runtime properly installed, then compiling as /MT would work, since the runtime will be included in the binary.
That may also explain while it works when you compile it as Debug mode, in debug mode, a debug version of the runtime is statically linked into the binary.
Look here for some discussion about the topic.
UPDATE
Another problem may be that the modules that the dll were compiled with different options, as stated in this msdn article:
All modules passed to a given invocation of the linker must have been
compiled with the same run-time library compiler option (/MD, /MT,
/LD).
Related
In Microsoft Visual Studio 2015 (v14.0) I have a solution that contains 3 projects.
Two of those projects are DLLs, and the other one is the executable.
The executable loads the DLLs at runtime and calls their functions and they exchange parameters; using Window's LoadLibrary, and GetProcAddress APIs.
In Release mode, when I set Runtime Library of my projects to Multi-threaded DLL everything works fine. This is Multi-threaded Debug DLL for Debug mode.
If I change to Multi-threaded for Release or Multi-threaded Debug for Debug I start getting Debug Assertion errors or Memory Access Violation errors and other kind of errors. (When I change it, I change it for all the projects in the solution.)
I need to use Multi-threaded option so that the executable won't need C++ runtime library on the target machine. How can I solve this issue?
It was because using /MT separates runtimes of entities (i.e. DLLs and executable), with each having their own runtime, hence their own heap, trying to allocate memory in one and freeing it in the other will end up in error. Because other modules were oblivious to the memory allocated.
On the other hand, with /MD all modules share the same runtime and as the runtime is aware of the memory allocated in one, it will be able to free it in the other. Because one instance of runtime manages the whole memory.
EDIT:
Thanks to dxiv comment.
I'm reading about /MT and /MD, but I'm a little confused about it
HEAR is something I don't completely understand :
/MT Causes your application to use the multithread, static version of the run-time library. Defines _MT and causes the compiler to place the library name LIBCMT.lib into the .obj file so that the linker will use LIBCMT.lib to resolve external symbols.
what does it mean?
If you link with /MD or /MDd your program is going to need the CRT dlls in order to run. typically they are called something like msvcp100.dll for the C++ runtime and msvcr100.dll for the C runtime. If you are deploying your application using an installer, you can add a package with these to your installer so the dlls are going to be there when someone runs the application. If on the other hand you are going to deploy your application just as a single stand alone exe, your users are going to need a copy of these dlls. The latest versions of these dlls usually come with windows itself (not the debug ones) but if your user is running an older version of windows it may not have the needed dlls.
Linking your application to the static version of the CRT saves this whole headache for the price that the exe is slightly bigger (since it contains the CRT in it)
If you do use /MT (Static CRT) you have to make sure that everything else that you statically link with uses /MT as well. otherwise you'll end up with an executable where part of the code uses the static CRT and part is still depends on the CRT DLL. Other than defeating the basic purpose not needing the CRT DLL, this can also cause other problems.
To make sure what DLLs your exe depends on you can use the dependency walker.
Is it possible to execute debug mode DLL with release mode EXE?
I am trying this scenario but EXE does not load the debug DLL and throws error "This application has failed to start...".
I know this is not good scenario to do but Due to certain requirements I have to make this work.
It can work if your dll interface has no dependencies on classes that may look different in debug and release.
e.g. std::string and std::vector in MSVC are not compatible in debug and release. (Fences ...)
So for example
std::string GetName();
will not work.
In additional new and delete should not be shifted because debug/release use different runtimes. But anyway you should always delete in the same context(dll/exe) as new.
Yes, this can work.
Your "application has failed to start" issue is most likely you copied a debug build of the DLL (built on your machine with Visual Studio), to a machine that did not have the DEBUG CRT installed. Usually copying over MSVCRTD(version).dll to the same directory as your program files solves this problem. I have a previous answer that covers some of this here.
Best bet is to always have all your binaries linked to the same dynamic MSVCRT DLL so they all share the same runtime.
Another easy workaround is to compile your DEBUG DLL to use the same flavor of the MSVCRT DLL (or statically link to the CRT). Somewhere in the VS project propery pages (code generation I think) is the dropdown for choosing the CRT. There's nothing wrong with linking the retail MSVCRT into a debug DLL - or statically linking.
The things to watch out for are when you have a different flavor of the debug C runtime linked to the different binaries. If you have the release MSVCRT dll linked for the EXE, but the debug MSCVRTD DLL for the DLL, that can cause problems in a few circumstances. This is because handles and memory blocks are tracked by two different instances of the CRT.
Examples:
If you allocate memory in the EXE, but free in in the DLL. And vice versa.
File handles opened with fopen() in the EXE, but used or closed in the EXE (and vice versa).
For any of the header files for the DLL's interface, having any sort of inline functions or methods implemented in the header file is an easy way to cause #1 or #2 to happen.
Sharing STL objects (std::string, std::list, std::vector) is a definite no-no for mixed CRT usage.
I am writing an C++ application that could be compiled under Linux (gcc 4.3) and Windows (MS VS08 Express).
My application uses third-party libraries,
On Linux , they are compiled as shared libraries, while
on Windows, there are two versions "Debug" and "Release".
I know that debug version provides extra support for debugging ( just like using -ggdb option in linux gcc, right? )
But I found that if my application is in debug version , the libraries must also be in debug version, otherwise the application will crash.
Why is there such a limit? It seems that there are no such limits in the linux world
Thank you very much!
The Debug configuration of your
program is compiled with full symbolic
debug information and no optimization.
Optimization complicates debugging,
because the relationship between
source code and generated instructions
is more complex.
The Release configuration of your
program contains no symbolic debug
information and is fully optimized.
Debug information can be generated in
PDB Files (C++) depending on the
compiler options used. Creating PDB
files can be very useful if you later
need to debug your release version.
Debug vs Release
It is also possible to debug your release build with the compiler flags.
Debugging Release Builds
Heap Layout - Guard Bytes to prevent overwriting
Compilation - Removing Assert/Debug Info
Pointer Support - Buffers around pointers to prevent seg faults
Optimization - Inline Functions
Common Problems When Creating Release Builds
To elaborate on Martin Tornwall. The various libraries linked when in Debug or Release
LIBCPMT.LIB, Multithreaded, static link, /MT, _MT
LIBCPMTD.LIB, Multithreaded, static link, /MTd, _DEBUG, _MT
CRT Libraries
Most likely, the Release and Debug versions are linked against different versions of the C++ Runtime library. Usually, a Debug build links against the "Multithreaded Debug DLL" runtime, whereas a Release build will generally link against "Multithreaded DLL". Loading DLLs whose runtime libraries are mismatched with that of the application will often lead to mysterious crashes.
You could try verifying that all your DLLs build against the same runtime library as your application, regardless of which configuration (Debug or Release) is active. Whether or not this is desirable is another question entirely.
The ability to choose which runtime library to link with enables the application developer to select the best feature set given her application's requirements. For example, a single-threaded application might incur performance penalties as a result of unnecessary thread synchronization if it is linked with a runtime library that is designed with thread safety in mind. Likewise, the consequences of linking a multi-threaded application against a single-threaded runtime could potentially be disastrous.
While I never intentionally link libraries that were built with different compiler settings, there isn't much point in doing so, I only know of the STL classes in the Dinkumware implementation (the one MSFT uses) to cause this problem.
They support a feature called 'iterator debugging' which is turned on by default in the Debug configuration. This adds members to the classes to aid the diagnostic code. Making them larger. This goes bad when you create the object in a chunk of code that was compiled with one setting and pass it to code that was compiled with the opposite setting. You can turn this off by setting the _HAS_ITERATOR_DEBUGGING macro to 0. Which is rather a major loss, the feature is excellent to diagnose mistakes in the way you use STL classes.
Passing objects or pointers between different libraries is always a problem if you don't carefully control the compile settings. Mixing and matching the CRT version and flavor gets you in trouble when you do so. This normally generates a warning from the linker, not sure what you did to not see it. There won't be one if the code lives in a DLL.
In Visual Studio, there's the compile flags /MD and /MT which let you choose which kind of C runtime library you want.
I understand the difference in implementation, but I'm still not sure which one to use. What are the pros/cons?
One advantage to /MD that I've heard, is that this allows someone to update the runtime, (like maybe patch a security problem) and my app will benefit from this update. Although to me, this almost seems like a non-feature: I don't want people changing my runtime without allowing me to test against the new version!
Some things I am curious about:
How would this affect build times? (presumably /MT is a little slower?)
What are the other implications?
Which one do most people use?
By dynamically linking with /MD,
you are exposed to system updates (for good or ill),
your executable can be smaller (since it doesn't have the library embedded in it), and
I believe that at very least the code segment of a DLL is shared amongst all processes that are actively using it (reducing the total amount of RAM consumed).
I've also found that in practice, when working with statically-linked 3rd-party binary-only libraries that have been built with different runtime options, /MT in the main application tends to cause conflicts much more often than /MD (because you'll run into trouble if the C runtime is statically-linked multiple times, especially if they are different versions).
If you are using DLLs then you should go for the dynamically linked CRT (/MD).
If you use the dynamic CRT for your .exe and all .dlls then they will all share a single implementation of the CRT - which means they will all share a single CRT heap and memory allocated in one .exe/.dll can be freed in another.
If you use the static CRT for your .exe and all .dlls then they'll all get a seperate copy of the CRT - which means they'll all use their own CRT heap so memory must be freed in the same module in which it was allocated. You'll also suffer from code bloat (multiple copies of the CRT) and excess runtime overhead (each heap allocates memory from the OS to keep track of its state, and the overhead can be noticeable).
I believe the default for projects built through Visual Studio is /MD.
If you use /MT, your executable won't depend on a DLL being present on the target system. If you're wrapping this in an installer, it probably won't be an issue and you can go either way.
I use /MT myself, so that I can ignore the whole DLL mess.
P.S. As Mr. Fooz points out, it's vital to be consistent. If you're linking with other libraries, you need to use the same option they do. If you're using a third party DLL, it's almost certain that you'll need to use the DLL version of the runtime library.
I prefer to link statically with /MT.
Even though you do get a smaller executable with /MD, you still have to ship a bunch of DLLs to make sure the user gets the right version for running your program. And in the end your installer is going to be BIGGER than when linking with /MT.
What's even worse, if you choose to put your runtime libraries in the windows directory, sooner or later the user is going to install a new application with different libraries and, with any bad luck, break your application.
The problem you will run into with /MD is that the target version of the CRT may not be on your users machine (especially if you're using the latest version of Visual Studio and the user has an older operating system).
In that case you have to figure out how to get the right version onto their machine.
from http://msdn.microsoft.com/en-us/library/2kzt1wy3(VS.71).aspx:
/MT Defines _MT so that multithread-specific versions of the run-time routines are selected from the standard header (.h) files. This option also causes the compiler to place the library name LIBCMT.lib into the .obj file so that the linker will use LIBCMT.lib to resolve external symbols. Either /MT or /MD (or their debug equivalents /MTd or /MDd) is required to create multithreaded programs.
/MD Defines _MT and _DLL so that both multithread- and DLL-specific versions of the run-time routines are selected from the standard .h files. This option also causes the compiler to place the library name MSVCRT.lib into the .obj file.
Applications compiled with this option are statically linked to MSVCRT.lib. This library provides a layer of code that allows the linker to resolve external references. The actual working code is contained in MSVCR71.DLL, which must be available at run time to applications linked with MSVCRT.lib.
When /MD is used with _STATIC_CPPLIB defined (/D_STATIC_CPPLIB) it will cause the application to link with the static multithread Standard C++ Library (libcpmt.lib) instead of the dynamic version (msvcprt.lib) while still dynamically linking to the main CRT via msvcrt.lib.
So if I am interpreting it correctly then /MT links statically and /MD links dynamically.
If you are building executable that uses other dlls or libs than /MD option is preferred because that way all the components will be sharing same library. Of course this option should match for all the modules involved i.e dll/lib/exe.
If your executable doesn't uses any lib or dll than its anyone's call. The difference is not too much now because the sharing aspect is not into play.
So maybe you can start the application with /MT since there is no compelling reason otherwise but when its time to add a lib or dll, you can change it to /MD with that of the lib/dll which is easy.