Изменения в строках, которые не будут выполняться, нарушают построение

Question

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

Это уже произошло дважды:

Во-первых, в строке в пути if-else выполняется только путь if, но когда я изменяю орфографию в пути else, программа через несколько минут падает в библиотеке std. С приложенным отладчиком я подтвердил, что измененные линии никогда не трогали. Когда я отменил изменение, оно снова работает хорошо.

Во-вторых, мое программное обеспечение снова падает на библиотеку std с проверкой out-of-array в стандартном деструкторе basic_string.

Я все сделал, вся библиотека соответствовала _HAS_ITERATOR_DEBUGGING.

Через 4 часа я обнаружил, что проблемный файл - TorrentFile.cpp/h.

Если я добавляю функцию (даже если она никогда не вызывается), в конце этого файла происходит сбой программы, но если ее там нет, ошибки нет. Код, вызывающий проблему:

std::vector<TorrentFileListPacket> TorrentFile::GetFileMap()
{
    std::vector<TorrentFileListPacket> vFiles;
    return vFiles;
};

Если я закомментирую этот код, сбой исчезнет.

Это действительно сводит меня с ума!

Я был разработчиком в течение 8 лет, и никогда раньше такого не видел!

Дополнительная информация

Моя память в порядке, я использую Visual Studio 2010 с пакетом обновления 1 (SP1) в Windows 7. Библиотека libTorrent от RasterBar, и она ссылается на повышение. Программное обеспечение использует MFC.

Answer 1

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

Ваша лучшая надежда - что-то вроде Purify или Valgrind, чтобы выследить его.

Answer 2

Вы, вероятно, хотите убедиться, что все ваши объектные файлы и библиотеки совместимы друг с другом ABI.

Многочисленные настройки компилятора изменят ABI. Особенно отладка и выпуск сборки и отладка итератора. Структура структуры для стандартных контейнеров обычно изменяется, когда вы включаете отладку итератора (которая, по моему мнению, включена по умолчанию для всех сборок отладки в msvc и отключена для сборок выпуска).

Таким образом, если один объектный файл, статическая библиотека или DLL, с которыми вы связываетесь, созданы с несовместимой конфигурацией, вы обычно видите очень странные варианты поведения. С libtorrent вам нужно убедиться, что вы собрали библиотеку с той же конфигурацией, с которой вы связываетесь с ней. Многие из определений TORRENT_ * фактически изменят некоторые аспекты структуры структуры или вызова функций. Убедитесь, что вы определили точно такой же набор из них в вашем клиенте, как и при сборке библиотеки. Один из простых способов решения этой проблемы - просто вставить все исходные файлы в ваш проект и собрать все вместе.

Answer 3

Если вы используете libtorrent в качестве DLL (или в этом случае повышение), скомпилированы ли они для одной и той же среды выполнения C?

Часто, когда я сталкиваюсь с этим типом проблемы, это происходит потому, что я делаю вызов в библиотеку, которая была скомпилирована с MinGW (который использует CRT из VS6.0) или более старой версией Visual Studio. Если память распределяется библиотекой, а затем освобождается вашим приложением, вы часто будете получать ошибки такого типа в деструкторе.

Если вы не уверены, вы можете открыть соответствующую DLL в таком инструменте, как Dependency Walker . Ищите зависимости MSVCRT.DLL, MSVCR100.DLL и т. Д.