Crash cuando se ejecuta la aplicación debido a la existencia de código no ejecutado en el archivo de origen - C++

Question

Estoy trabajando en un problema bastante complicado que he estado en, literalmente, de una semana. He golpeado una pared muy dura y me duele la frente por golpearla, así que espero que alguien me pueda ayudar.

Estoy utilizando Visual Studio 2005 para este proyecto - He instalado 2008, pero estaba corriendo en problemas similares cuando lo probé.

tenemos una aplicación que actualmente trabajan compilado con OpenCv1.1 y yo estoy tratando de actualizar a 2.2. Cuando cambiamos de forma estática al enlace a las nuevas bibliotecas, la aplicación falla, pero solo en el modo de lanzamiento. Por lo tanto, el enlace dinámico y la depuración funcionan bien.

El bloqueo está en std::vector al llamar al push_back.

Entonces me encontré con una aplicación de prueba de ejemplo que se ejecuta un código básico en OpenCV que funciona muy bien y luego tomó ese mismo código y lo añadió a nuestra aplicación. Ese código falla.

entonces destripado la aplicación por lo que no instanciar objetos de código, excepto la interfaz gráfica de usuario principal y 1 clase que llama ese código y todavía se estrelló. Sin embargo, si ejecuté ese código directamente en la GUI principal, funcionó bien.

luego empecé comentando enormes cantidades de la aplicación (en componentes que nunca debe ser instanciados) y, finalmente, me abrí camino hacia abajo, abajo, abajo hasta que ...

tengo una clase que tiene un método

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

Si este método se define en el encabezado, el código de prueba funciona, pero si este código se define en el archivo cpp, se bloquea. Además, si uso std::vector<double> en lugar de int, también funciona.

Luego intenté jugar con las opciones del compilador y si tengo las optimizaciones desactivadas (/ Od) y Expansión de la función en línea configurada en Sólo __inline (/ Ob1) funciona incluso con el código en el archivo cpp.

Por supuesto, si volvemos a la aplicación con vísceras y cambiar las opciones del compilador por sí mismos, de que se estrelle.

Si alguien tiene alguna idea sobre esto, hágamelo saber.

Gracias, Liron

Answer 1

ARGH! Solución resuelta.

En nuestra solución que habíamos definido _SECURE_SCL = 0, pero en las bibliotecas 3 ª parte tuvimos la construcción, que es indefinida (lo que significa = 1). Establecer _SECURE_SCL en 0 supuestamente reduce los tiempos de ejecución drásticamente, pero tiene que hacerse de la misma manera en todas las librerías incluidas, de lo contrario tratarán los tamaños de las matrices de forma diferente.

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

Eso fue una semana divertida.

Answer 2

Las clases STL, como vector de <>, tienen una falta de correspondencia entre el diseño y la liberación versiones de depuración, causada por el apoyo iterador depuración. Su problema se comporta exactamente como el tipo de problema que tiene cuando vincula una compilación de depuración de .lib o DLL en la versión de lanzamiento de su aplicación e intercambia un objeto STL entre ellos. El resultado es la corrupción de montón y las excepciones de violación de acceso.

Comprueba tres veces la configuración de compilación y asegúrate de que solo vinculas la versión de lanzamiento de .libs en tu compilación Release y la compilación de depuración de .libs en tu compilación Debug.

Answer 3

podría intentar:

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