Crash when running application due to existence of unexecuted code in source file - c++

Question

I'm working on a pretty tricky problem that I've been on for literally a week now. I've hit a very hard wall and my forehead hurts from banging it so I'm hoping someone can help me out.

I am using Visual Studio 2005 for this project - I have 2008 installed but was running into similar issues when I tried it.

We have an application currently working compiled against OpenCv1.1 and I'm trying to update it to 2.2. When we switch over statically link to the new libs, the application crashes - but only in release mode. So dynamic linking and debug both work fine.

The crash is in std::vector when calling push_back.

I then came up with a sample test application which runs some basic code in opencv which works fine and then took that exact same code and added it to our application. That code fails.

I then gutted the application so it didn't instantiate any code objects except the main gui and 1 class which called that code and it still crashed. However, if I ran that code directly in the main gui, it worked fine.

I then started commenting out huge amounts of the application (in components that should never be instantiated) and eventually I worked my way down down down until...

I have a class that has a method

void Foo()  
{  
    std::vector<int> blah;  
    blah.begin();  
}  

If this method is defined in the header, the test code works, but if this code is defined in the cpp file, it crashes. Also, if I use std::vector<double> instead of int, it also works.

I then tried to play with the compiler options and if I have optimizations turned off (/Od) and Inline Function Expansion set to Only __inline (/Ob1) it works even with the code being in the cpp file.

Of course, if we go back to the ungutted application and change those compiler options by themselves, it crashes.

If anyone has any insights on this, please let me know.

Thanks, Liron

Answer 1

ARGH! Solution figured out.

In our solution we had defined _SECURE_SCL = 0, but in the 3rd party libs we had build, that was undefined (which means = 1). Setting _SECURE_SCL to 0 supposedly reduces runtimes drastically, but it has to be done the same across all included libs otherwise they will treat array sizes differently.

http://msdn.microsoft.com/en-us/library/aa985896%28v=vs.80%29.aspx

That was a fun week.