Интересно, есть ли хороший способ найти исходный код, который вызывает ошибку повреждения кучи, учитывая адрес памяти данных, которые были записаны «вне» выделенного блока кучи в Visual Studio;
Выделенный (0008) свободный элемент списка 26F7F670 имеет неправильный размер (мертвый)
(Попытка записать некоторые заметки о том, как найти ошибки памяти)
Начните с установки windbg:
http://www.microsoft.com/whdc/Devtools/Debugging/default.mspx
Затем включите pageheap следующим образом:
gflags.exe –p /enable yourexecutable.exe /full
Это будет вставлять недоступную для записи страницу после каждого выделения кучи.
После запуска исполняемого файла из Windbg любые записи вне кучи теперь будут перехватываться этим отладчиком. Чтобы перевернуть кучи страниц, используйте это:
gflags.exe -p /disable yourexecutable.exe
Дополнительные сведения об использовании кучи страниц здесь.
/p не -p. Он не узнал -p.
- person TankorSmash; 13.01.2017
Для Windows 10 вы можете включить < strong>PageHeap в инструменте GFlags, этот инструмент входит в состав Инструменты отладки для Windows.
Параметры кучи страниц в GFlags позволяют выбрать стандартную проверку кучи или проверку кучи на всю страницу. Остерегайтесь, полная проверка кучи использует полную страницу памяти для каждого выделения, поэтому это может привести к нехватке системной памяти.
Чтобы включить кучу страниц в GFlags:
• Чтобы включить стандартную проверку кучи страниц, стандартная версия будет записывать шаблон в конце каждого выделения кучи, а затем проверять шаблон при освобождении выделений.
Для проверки всех процессов используйте:
gflags /r +hpa
gflags /k +hpa
для одного процесса использования:
gflags /p /enable ImageFileName
• Чтобы включить полную проверку кучи страниц для одного процесса, этот параметр помещает недоступную страницу в конец каждого выделения, чтобы программа немедленно останавливалась, если пытается получить доступ к памяти за пределами выделения. используется в одном процессе из-за большого потребления памяти.
gflags /i ImageFileName +hpa
gflags /p /enable ImageFileName /full
Две приведенные выше команды взаимозаменяемы.
Примечание. Все упомянутые выше параметры кучи страниц являются общесистемными параметрами, хранящимися в реестре (кроме /k), и действуют до тех пор, пока вы их не измените. Параметр /k — это параметр флага ядра, установленный для этого сеанса, который будет потерян при завершении работы Windows
Еще одним полезным инструментом является Средство проверки приложений, но оно не является частью средств отладки для Windows, а включено в Комплект разработки программного обеспечения для Windows (SDK).
Может быть, вы можете попробовать средство проверки приложений Microsoft. Однажды он решил аналогичную проблему для меня, включив дополнительные проверки операций с кучей. На мой взгляд, случайность поврежденного адреса связана с тем, что куча может быть «незначительно» повреждена, и проблема не проявится, пока с кучей не произойдет что-то серьезное (например, массивное выделение/освобождение).
Вы можете установить точку останова на запись в адрес памяти. Затем отладчик покажет вам код, который записывает в это место, но вам все равно нужно выяснить, какая из операций записи вызывает проблему.
Вероятно, уже слишком поздно, но если он компилируется с помощью gcc и может работать в Linux, вы можете использовать valgrind, чтобы найти источник проблемы (я не помню флаги, я использовал его только один раз с большим успехом).
дополнительная информация о Gflags и PageHeap (что очень помогло): http://msdn.microsoft.com/en-us/library/windows/hardware/ff549561%28v=vs.85%29.aspx
Я предполагаю C++ в качестве языка.
Если ошибка воспроизводима и поврежденный адрес всегда один и тот же, можно поставить точку останова данных для остановки программы при записи по этому адресу.
Убедитесь, что все библиотеки, на которые вы ссылаетесь, скомпилированы в той же версии CLR, что и приложение, в котором вы работаете, — все в выпуске или все в отладке.
Когда вы компилируете в Debug и Release, вы на самом деле ориентируетесь на две разные версии библиотеки времени выполнения C. Эти версии совершенно разные, они используют разные стратегии выделения памяти и используют разные кучи. Но самое главное, что нужно знать, это то, что они НЕ совместимы друг с другом.
Библиотека времени выполнения версии C выделяет память, как и ожидалось, в то время как отладка добавит дополнительную информацию, такую как защитные блоки для отслеживания переполнения буфера и местоположение, вызывающее функцию выделения, и, в свою очередь, она выделяет больше памяти, чем версия.
Если вы связываете свое приложение со смесью библиотек DLL, которые были созданы в Release и Debug, вы, скорее всего, в конечном итоге попытаетесь удалить объект в одной CLR, который был создан в другой. Это означает, что вы будете пытаться освободить больше или меньше памяти, чем было выделено для объекта, и это может привести к повреждению кучи.
Вы должны создать свое приложение, а также подключиться к библиотекам, которые созданы в той же конфигурации, либо Release, либо Debug.
Эта проблема может возникнуть, особенно в модулях, которые компилируются разными компиляторами.
Есть обходной путь, который я упомяну, но не рекомендую. Если по какой-то причине вам все еще нужно собирать в разных режимах, этот обходной путь позволит выделить и освободить всю память из одной и той же общей кучи. API GetProcessHeap позволит вам получить доступ к общей куче через различные модули. Используя HeapAlloc и HeapFree, вы можете выделять и освобождать память в общей куче. Примечание. HeapAlloc и HeapFree должны заменить все вызовы malloc и free в вашем приложении.
