2

I have a C++ application that breaks when I set the Platform Toolset to VS 2012(v110) and VS 2013. It works however if I target VS2012 with Windows XP support. If I target VS2008 or VS2010, it works fine. I only have a problem when running the application without a debugger attached, and compiled in release mode.

I've tried to analyze what happened, but I seem to be getting those special "impossible" errors caused by some kind of memory corruption bug.

The only special thing I can think of is that I also use a library in this application. This library has it's platform toolset set to VS 2010. The application will still crash even if the library is built in debug mode. Also, both the library and application are 32bit applications.

Where should I start looking for why my app is broken? The application itself is quite simple and I see no immediate undefined behavior. However, the library is another story and is quite complex and involved, so I need pointers as to what to look for.

Earlz
  • 62,085
  • 98
  • 303
  • 499
  • Use Visual Memory Leak tool – DarkZeros Nov 13 '13 at 16:51
  • The tough thing about Undefined Behavior is that it's not always easy to see. You could have some very subtle bug which resulted in UB which had no ill effects in VS 2010 but suddenly starts to cause problems in VS 2012 due to some change in how the compiler or runtime works. – Adam Rosenfield Nov 13 '13 at 16:52
  • 1
    Are you using the library dynamically? If so you may have a different CRT in the application compared to the library, and this can cause all sorts of allocation/deallocation funkiness. – Joris Timmermans Nov 13 '13 at 16:55
  • 1
    Since you are switching the runtime of your application are there any dlls that you are using with your application? If there are dlls are you also switching those to ones compiled with the same runtime? I just answered a question about that yesturday :http://stackoverflow.com/questions/19944589/how-bad-is-it-to-mix-and-match-vc-runtime-dlls-in-one-process/19944935#19944935 – drescherjm Nov 13 '13 at 16:55
  • @MadKeithV yes, the library is loaded dynamically. I never thought this would cause problems though. I didn't think library compile tools needed to match application compile tools – Earlz Nov 13 '13 at 17:06

1 Answers1

0

Possibly you have a heap corruption bug that is being "fixed" by the fault tolerant heap and the new compiler tags the executable as not needing the fault tolerant heap.

Joshua
  • 40,822
  • 8
  • 72
  • 132