C++ assert() завершается с ошибкой, не выдавая сообщения об ошибке или строки, в которой произошел сбой

У меня странная проблема в моем коде. У меня есть много утверждений, разбросанных по коду, и все они работают нормально. Всякий раз, когда утверждение терпело неудачу, я получал сообщение с номером строки, где произошел сбой. Сегодня я написал еще одно утверждение в функции, которая загружает файл. Просто хотел убедиться, что фай существует. Очень простое утверждение. Вот соответствующий код:

//Check that the file exists and can be opened
FILE* f = fopen(filename, "rb");

#ifdef ASSERTIONS_ON
    assert(f!=NULL);//@problem For some reason while all other asserts work, this one just crashes the program without reporting line
#else
    if(f  == NULL)
        return MODEL_LOAD_FILENOTFOUND;
#endif

fclose(f);

Я знаю, что это не очень помогает, но просто хотел продемонстрировать, в чем моя проблема. Моя ОС — Windows 7. Компилятор — GCC. Сообщение об ошибке, которое я получаю от Windows, является обычной ошибкой времени выполнения, но без сообщения о строке:

«Приложение запросило среду выполнения необычным образом завершить его. Пожалуйста, свяжитесь со службой поддержки приложения для получения дополнительной информации»

В чем может быть проблема? Что может привести к тому, что ошибка утверждения просто запросит завершение без сообщения строки, в которой это происходит, в то время как в любом другом случае в том же коде он работает так, как предполагалось? Спасибо заранее за любую помощь!


person Lefteris    schedule 26.11.2010    source источник


Ответы (1)


Вы, скорее всего, где-то FUBAR'ировали стек перед выполнением assert.

person inetknght    schedule 26.11.2010
comment
Черт возьми, вы правы ... Я не знал, что испорченный стек может привести к такому поведению утверждений. Я только что переместил assert(0); вокруг того места, где я получил ошибку, и нашел оскорбительную функцию. Довольно мило. Спасибо за ответ дружище - person Lefteris; 26.11.2010
comment
У меня есть еще один дополнительный вопрос, если вы можете ответить на него. Кажется, это снова случилось со мной. Сейчас не могу определить причину. Какие проблемы со стеком могут привести к этому? Есть ли верный способ их обнаружить? Я явно делаю что-то не так - person Lefteris; 26.11.2010
comment
Если я не ошибаюсь, этот сайт на самом деле не для обсуждения этого, и на самом деле у IMO плохие уведомления об ответах на сообщения, поэтому вам, возможно, было бы лучше задать второй вопрос. В любом случае, я не слишком хорошо знаком с GCC, но я бы начал с установки точки останова где-то, где вы знаете, что он получает поврежденный стек, а затем отслеживал в поисках кода, который уничтожит стек. . На самом деле это проще, чем вы думаете: если кода нет в вашей текущей функции и вы не можете следить за стеком, выполните поиск в своем коде, чтобы найти функции, которые вызывают функцию, в которой... - person inetknght; 26.11.2010
comment
... ваша текущая точка останова. Продолжайте искать код, который разрушает стек. Поскольку вы, вероятно, новичок (сломанный стек так легко избежать, IMO), я также упомяну, что некоторые вредоносные библиотеки могут нарушать ваш стек, поэтому убедитесь, что вы проверяете стек до и после вызовов. к библиотечным функциям. Это все, что я могу сказать, не имея доступа к вашему коду. - person inetknght; 26.11.2010
comment
Спасибо большое. Ну, я далеко не новичок, но это правда, что я потерял связь с полем больше года. Так что я продолжаю вспоминать :) - person Lefteris; 26.11.2010