0

I am building an application whose output is libraries that end up being used by another client application. I recently discovered I was building my application in debug mode using /MDd for code generation (debug CRT libraries) and that the client application was built against release CRT even using /MD in debug mode. Hence this can cause some memory heap corruption errors. To confirm, this I tested everything in release mode and there it appears to work fine.

To address the issue, I tried doing a release with debug info build (/MD) too and link the debug build of the client application against this relwithdebinfo build, but now I am seeing some strange behavior in the client application when testing my example. To be precise, when I assign a string, say using: 

std::string client_str = some_namespace_in_my_library::class_name::string_name,

I find that client_str is not assigned, rather remains empty. This was working fine when everything was built in debug (when mix and match was present). Any ideas why this is happening? The string in the namespace referenced above is a static public member of the class, class_name. All this is on MS VC++ 2005. Any advice/help is appreciated very much. Thanks!

squashed.bugaboo
  • 1,267
  • 2
  • 19
  • 34
  • possible duplicate of [Building application in debug with release CRT with dependency issues on boost](http://stackoverflow.com/questions/11074727/building-application-in-debug-with-release-crt-with-dependency-issues-on-boost) – Bo Persson Jun 18 '12 at 20:46
  • Thanks @Persson: No, it is not a duplicate (I posted that one as well). Read the question/post. I am trying something different here. Related, yes.. but not a duplicate. I could integrate this into the original question there as an edit (or recent action). – squashed.bugaboo Jun 18 '12 at 20:52
  • 2
    When mixing debug and release code, **anything** bad can happen. I see this as another instance of the same problem you had in the other question. The advice is just not to try this. Sorry! – Bo Persson Jun 18 '12 at 20:58
  • Can you clarify? Say you have an application and you are linking against a 3rd party library that you don't need to debug into (and often cannot). Why would you want to have the debug versions of those libraries to link against? Likewise, many applications build their debug versions against release CRT. So given that, what exactly are you suggesting? – squashed.bugaboo Jun 18 '12 at 22:38
  • I'm not sure about VS2005, but I do know that VS2010 adds extra debug helper fields to containers and iterators (including `std::string`) in debug mode. This means that debug and release versions of objects have different sizes, and things like assignment is definitely not going to work. I suspect you run into something similar here. – Bo Persson Jun 19 '12 at 06:30

1 Answers1

1

My guess would be that you are violating the one definition rule because of checked iterators. See: http://msdn.microsoft.com/en-us/library/aa985896(v=vs.80).aspx

The problem is that like Bo above already wrote, structs and classes used in the STL are not of the same size in debug and release builds, and more problematic with and without checked iterators.

One other reason could be, that the default value for checked iterators changed with the visual studio version for release builds. While it was on by default for vs2005 and vs2008, it is off for 2010+ (check all dependency libs and how they are built!)

The most important rule here is: make sure every compilation unit uses exactly the same settings, both for _SECURE_SCL and _HAS_ITERATOR_DEBUGGING.

I remember one more thing, but can't find the link now: even though debug builds with and without checked iterators are meant to be compatible, there were bugs with vs2005 where this was not correctly implemented and I think fixed in a later version.

Gerstmann
  • 4,838
  • 6
  • 33
  • 55
peter
  • 11
  • 1