2

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.

Sahil Mittal
  • 20,697
  • 12
  • 65
  • 90
Swanand
  • 4,027
  • 10
  • 41
  • 69
  • When you use the debugger, where is it crashing? – brian beuning Sep 05 '13 at 12:40
  • @brianbeuning at the "return" statement o_O – Swanand Sep 05 '13 at 13:25
  • That usually means one of two things: (1) An object on the stack destructor is crashing (and if the destructor is calling delete, then see my answer) or (2) you have overflown an array on the stack and corrupted the function return address on the stack. – brian beuning Sep 05 '13 at 22:57
  • try here: http://stackoverflow.com/questions/312312/what-are-some-reasons-a-release-build-would-run-differently-than-a-debug-build/312352 – peterchen Sep 06 '13 at 09:47

2 Answers2

2

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

brian beuning
  • 2,836
  • 18
  • 22
0

/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).

Community
  • 1
  • 1
papirrin
  • 2,004
  • 22
  • 30
  • I had seen that link.... But this is happening on my very own development machine... Has every sort of thing installed! (I tried on few other machines too, to be safe) – Swanand Sep 05 '13 at 12:04