Странное нарушение прав доступа ifstream под Visual Studio 2012

У меня есть этот кусок кода, работающий на Linux с г ++:Странное нарушение прав доступа ifstream под Visual Studio 2012

GLuint Shader::initShader_(GLenum shaderType, const std::string& shaderFilename) 
{ 
    std::ifstream inputFile(shaderFilename.c_str()); 
    if (inputFile.is_open() == false) 
    { 
     std::ostringstream oss; 
     oss << "Shader " << shaderFilename << " doesn't exist!"; 
     print(LOG_LEVEL::ERROR, oss.str()); 
    } 
    ... 
}

где три точки представляют собой некоторый код. На g ++ и Visual Studio (2012) код компилируется. Но с Visual Studio первая строка вызывает исключение нарушения доступа. Это происходит при открытии файла, и отладчик перенаправляет меня на do_always_noconv, но я не понимаю проблему.

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

Кто-нибудь уже сталкивался с этой проблемой или имеет идею? Снова он работал без каких-либо проблем с Linux с g ++.

Благодарим за помощь.

источник

2014-03-09 Anonymous

Исключение нарушения прав доступа не указывает на проблему с файлом, но с представлением объекта ifstream или строки в памяти. Начните искать повреждение памяти.

Убедитесь, что вы ссылаетесь на правильные библиотеки GLSDK для вашего типа сборки. например Отладочные сборки должны ссылаться на библиотеки отладки, а выпускные сборки должны ссылаться на библиотеки релизов.

источник

2014-03-09 20:25:21 PaulH

Спасибо за ваш ответ, я создаю проект в режиме отладки, а библиотеки предназначены для режима отладки (есть d в конце microsoft libs). –

Я действительно не понимаю: я создал проект с теми же библиотеками и свойствами с несколькими строками для тестирования строк и ifstreams, и он работает очень хорошо ... –

Я имел в виду OpenGL SDK-библиотеки, но хорошо проверить Microsoft тоже. Если вы подтвердили, что все ваши библиотеки верны для вашего типа проекта, то повреждение памяти должно быть в другом месте. начните искать места, где вы пишете массивы и проверяете длины этих записей. Рассмотрите возможность использования Application Verifier для проверки использования вашей памяти. – PaulH

Как уже говорилось в PaulH, я проверил некоторый код массива, который я написал недавно, и ошибка возникла из-за неправильных индексов и указателей. Однако я до сих пор не понимаю, почему ошибки в коде массива имеют какое-то отношение к ifstream. Благодаря PaulH!

источник

2014-03-10 19:53:22

Ошибка в коде переписала часть объектов std :: string или std :: ifstream, так что когда вы использовали эти объекты, они перестали действовать и стали причиной нарушения доступа. – PaulH

Странное нарушение прав доступа ifstream под Visual Studio 2012

ответ

Смежные вопросы