Есть ли Valgrind Memcheck, как инструмент для Windows, чтобы отлаживать использование после бесплатных ошибок?

Завершая свою работу, я регулярно сталкиваюсь с довольно распространенной ошибкой программирования - с помощью некоторого объекта, который уже был освобожден. Это вызывает UB в С++. В Linux такие проблемы обычно решаются с помощью утилиты Valgrind Memcheck. Из Руководство по Memcheck:

Memcheck пытается установить, к чему может относиться незаконный адрес, так как это часто полезно. Итак, если он указывает на блок памяти который уже был освобожден, вы будете проинформированы об этом, а также где блок был освобожден.

Memcheck предоставляет мне стек вызовов, где объект был освобожден, и я могу продолжить и отладить проблему. Есть ли аналогичный инструмент для Windows с одинаковой функциональностью, желательно бесплатно?

Ответ 1

Согласно документации Dr. Memory, есть опция -delay_frees_stack с точно такой же функциональностью Valgrind. Из Ссылка на опцию:

-delay_frees_stack 
default: false 
Record callstacks on free to use when reporting use-after-free or other errors that overlap with freed objects. There is a slight performance hit incurred by this feature for malloc-intensive applications.

Также приведен пример ошибки сообщенной Dr. Memory:

Here is another example, using the -delay_frees_stack option to obtain the callstack of the freed memory:

Error #8: UNADDRESSABLE ACCESS: reading 0x001338a8-0x001338ac 4 byte(s)
# 0 unaddr_test1                    [e:\derek\drmemory\git\src\tests\suppress.c:110]
# 1 test                            [e:\derek\drmemory\git\src\tests\suppress.c:269]
# 2 main                            [e:\derek\drmemory\git\src\tests\suppress.c:297]
Note: @0:00:02.141 in thread 3024
Note: next higher malloc: 0x001338e8-0x00133938
Note: prev lower malloc:  0x001337e8-0x00133820
Note: 0x001338a8-0x001338ac overlaps memory 0x001338a8-0x001338c4 that was freed here:
Note: # 0 test                            [e:\derek\drmemory\git\src\tests\suppress.c:269]
Note: # 1 main                            [e:\derek\drmemory\git\src\tests\suppress.c:297]
Note: instruction: mov    (%eax) -> %eax

Ответ 2

Как заметил Лейлин Чен в своем ответе на этот вопрос, попробуйте один из них:

р. Память: https://github.com/dynamorio/drmemory

UMDH: http://support.microsoft.com/kb/268343

AppVerifier: http://msdn.microsoft.com/en-us/library/dd371695%28v=vs.85%29.aspx

Ответ 3

Метод, который работал у меня, заключался в том, чтобы написать собственный менеджер памяти, который предоставляет глобальным операторам "новое" и "удалить", и блокировать каждый освобожденный /VirtualProtect. Таким образом, любая попытка использовать свободную память немедленно вызовет нарушение прав доступа, которое вы можете поймать и отладить. Однако, чтобы это сделать, вы должны "захватить" всю доступную память (или 3/4 ее), используя что-то вроде VirtualAlloc, и каждый возвращаемый вами блок памяти (из этого первоначально выделенного блока) должен быть PAGE_SIZE выровнен (см. документацию GetSystemInfo), иначе вы не сможете надежно заблокировать ее. Это означает, что даже тривиальное приложение может потребовать большой объем памяти для использования этого метода.

Что касается "альтернативы valgrind для окон", я не слышал об этом. Кто-то где-то сказал, что возможно скомпилировать/использовать valgrind с cygwin, но я не знаю, верно это или нет.

Ответ 4

Вот доблестная попытка Валгринга, и я желаю им всего наилучшего:

http://sourceforge.net/p/valgrind4win/wiki/Home/

Я боюсь, что для реализации надлежащего "Valgrind для Windows" требуется доступ к исходному коду Windows.

IOW: Когда свиньи летают.

Ответ 5

Что лучше всего для меня использовало Visual leak Detector, все, что мне нужно было сделать, это включить:

#include <vld.h>

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