Рейтинг:
28
Jochen Arndt
Вы можете перехватывать такие исключения при включении SEH (структурированная обработка исключений, см. -EH (модель обработки исключений)[^]).
Поскольку такие исключения происходят асинхронно, они являются фатальными ошибками, и приложение должно завершиться. Таким образом, перехват таких исключений не имеет никаких преимуществ для сборки релизов, кроме создания собственного сообщения об ошибке или регистрации их в журнале.
Но вы можете использовать их временно, чтобы приблизиться к источнику проблемы, вставив блоки try catch в видные места кода. Как только у вас есть меньшая часть кода, которая вызывает исключение, проверьте его, чтобы найти вероятные источники.
Если это еще не сделано, убедитесь, что все переменные указателя инициализированы и выполняются assert() проверяет наличие отладочных сборок.
Чтобы прибить его к ногтю:
У вас есть ошибка в коде, которую необходимо исправить. Как правило, он может быть обработан путем перехвата исключения из-за асинхронности.
ssyuvaraja
- Привет, спасибо. Я пытаюсь выяснить, является ли точное местоположение причиной проблемы. Это будет полезно, с журналом и проверкой его. Его цель развития-решить этот вопрос. Огромное спасибо.
[no name]
Неинициализированные проблемы указателя, которые я ожидал бы обнаружить в начале пробега. Assert () - это хороший совет, и мне интересно, покажет ли что-нибудь стресс-тестирование в debug. Мой 5.
Jochen Arndt
Спасибо.
При использовании утверждений переменные указателя должны быть инициализированы нулем, а также очищены снова, когда это необходимо (например, после освобождения памяти). В противном случае утверждения бесполезны. Может быть, это было недостаточно ясно объяснено.
Рейтинг:
2
KarstenK
Это нарушение доступа к памяти. Ваша программа обращается к недопустимой памяти. Обычно вводящий в заблуждение указатель: удаленная память или указатель установлен или используется неправильно.
Вы должны отладить строку кода, в которой это происходит. Я знаю опцию в Visual Studio, чтобы попасть в точку отладки при изменении памяти или значения, но не помню, где она сейчас находится... (извините)
Прочитайте Использование Точек Останова: Дополнительная Информация чтобы найти способ установить полезную точку останова и выполнить отладку.
ssyuvaraja
- Привет, спасибо. да это из-за памяти. Адрес памяти для указателя работает нормально уже более суток. При длительном запуске в определенный момент память повреждается, что вызывает проблему. Поэтому я хочу поймать эту проблему. Есть ли какой-нибудь способ использовать try...catch для этого, чтобы справиться с этим.
Stefan_Lang
Вы можете добавить код для проверки значений указателей не для null, а для чисел ниже 1024. Это не 100% надежно, но когда у вас есть проблемы с выделением памяти, недопустимые указатели будут находиться в этом диапазоне большую часть времени. В любом случае, ни один допустимый указатель не должен находиться в этом диапазоне, поэтому вы не будете ловить ложные срабатывания.
P. s.: Я читал это в какой-то теме на SO некоторое время назад. К сожалению, я больше не могу найти эту ссылку, поэтому не могу сказать, что это за источник для 1024. Однако в UNIX, и, вероятно, некоторые (большинство? все?) Дистрибутивы Linux, адреса ниже 0x8000 рассматриваются как ошибка seg. Я не нашел такого ограничения для Windows 10, но Win32 (без набора коммутаторов /3gb) используется для резервирования адресного пространства ниже 0x10000.
KarstenK
Добавлена ссылка. Вы должны отладить свое приложение - другого пути нет. Некоторые утечки памяти минимальны, остаются скрытыми из-за большего буфера или находятся только в некоторых случайных кодовых путях и их так трудно обнаружить.