Сбой при запуске приложения из-за наличия неисполненного кода в исходном файле - c ++ - PullRequest
10 голосов
/ 03 марта 2011

Я работаю над довольно сложной проблемой, которой занимаюсь буквально неделю. Я ударился о очень твердую стену, и мой лоб болит от удара, поэтому я надеюсь, что кто-то может мне помочь.

Я использую Visual Studio 2005 для этого проекта - у меня установлен 2008, но у меня возникали похожие проблемы, когда я его пробовал.

У нас есть приложение, в настоящее время работающее скомпилировано с OpenCv1.1, и я пытаюсь обновить его до 2.2. Когда мы статически переключаем ссылки на новые библиотеки, приложение вылетает - но только в режиме релиза. Так что динамическое связывание и отладка работают нормально.

Сбой в std::vector при вызове push_back.

Затем я создал пример тестового приложения, которое запускает некоторый базовый код в opencv, который отлично работает, а затем взял тот же самый код и добавил его в наше приложение. Этот код не работает.

Затем я выпотрошил приложение, чтобы оно не создавало никаких объектов кода, кроме основного графического интерфейса и 1 класса, который вызывал этот код, и он все еще падал. Однако, если я запускал этот код непосредственно в основном графическом интерфейсе, он работал нормально.

Затем я начал комментировать огромное количество приложения (в компонентах, которые никогда не должны создаваться), и в конце концов я спустился вниз до ...

У меня есть класс, у которого есть метод

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

Если этот метод определен в заголовке, тестовый код работает, но если этот код определен в файле cpp, происходит сбой. Кроме того, если я использую std::vector<double> вместо int, это также работает.

Затем я попытался поиграть с параметрами компилятора, и если у меня отключены оптимизации (/ Od) и для параметра Расширение встроенной функции установлено значение Only __inline (/ Ob1), это работает даже с кодом, находящимся в файле cpp.

Конечно, если мы вернемся к непрошеному приложению и изменим эти параметры компилятора самостоятельно, оно выйдет из строя.

Если у кого-то есть идеи по этому поводу, пожалуйста, дайте мне знать.

Спасибо, Liron

Ответы [ 3 ]

8 голосов
/ 03 марта 2011

ARGH! Решение разобрался.

В нашем решении мы определили _SECURE_SCL = 0, но в сторонних библиотеках, которые у нас были, это было неопределенным (что означает = 1). Установка _SECURE_SCL в 0 предположительно значительно сокращает время выполнения, но это должно быть сделано одинаково для всех включенных библиотек, иначе они будут по-разному обрабатывать размеры массива.

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

Это была веселая неделя.

6 голосов
/ 03 марта 2011

Классы STL, такие как vector <>, имеют несоответствие компоновки между выпуском и сборками отладки, вызванное поддержкой отладки итератора.Ваша проблема ведет себя точно так же, как и проблема, с которой вы сталкиваетесь, когда связываете отладочную сборку .lib или DLL в сборке выпуска вашего приложения и обмениваетесь между ними объектом STL.В результате возникают повреждения кучи и нарушения прав доступа.

Тройная проверка параметров сборки и проверка того, что вы когда-либо связываете только сборку выпуска .libs в вашей сборке выпуска и отладочную сборку .libs в вашей отладке.строить.

0 голосов
/ 03 марта 2011

не могли бы вы попробовать:

void Foo()  
{  
    std::vector<int> blah;
    blah.reserve(5);
    blah.begin();  
} 
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...