Тестирование программы С++

@_Valera_ · Регистрация: 27.01.2015

Какие есть программы что бы проверить код на утечку памяти , мусор и другие сюрпризы?

Спасибо!

@rikimaru2013 · 01.11.2015, 22:29

Сообщение от _Valera_

проверить код на утечку памяти

Visual Studio 2015

Сообщение от _Valera_

мусор

Нефиг гавнокодить

Ну и статический анализатор вон готовит Майерс и КО

Сообщение от _Valera_

другие сюрпризы

тут нужны тестеры

@_Valera_ · 01.11.2015, 22:30 **[ТС]**

Сообщение от rikimaru2013

Visual Studio 2015

не могу, нужно выполнять на 13...

Сообщение от rikimaru2013

тут нужны тестеры

да, но программист же тоже должен как то протестить...

@rikimaru2013 · 01.11.2015, 22:37

Сообщение от _Valera_

тоже должен как то протестить...

Программисты проверяют работает ли если ити от точки А к точки Б напрямую. Все другие пути: это долго и рутино, и явно лучше использовать силу подешевле.

К тому же существуют С++ тесты - вот сейчас сяду читать как их писать. Писал для C#:
- вся их суть. Вы пишите класс, к примеру, дробь и пишите что-то типа:

C++

void test1_toFloatMethod()
{
Fraction a(3, 4);
double temp = a.toFloat();
double expected = 0.75;
Equals(temp, expected);
}
void test2_toFractionMethod()
{}

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

@_Valera_ · 01.11.2015, 22:41 **[ТС]**

Сообщение от rikimaru2013

программисты леньтяи

+

Да просто пишу сейчас на cocos2dx - там все на указателях, и память вроде как сама потом убирается, но хотелось бы быть уверены что это так, вот и ищу как проверить потери памяти!

@Melg · 01.11.2015, 22:48

_Valera_, На предмет ошибок работы с памятью и потоками, Вам в помощь - valgrind, как не интрузивное средство, а так же address-sanitizer, memory-sanitizer, thread-sanitizer - как интрузивное. Наконец используйте юнит тестирование, отделяйте бизнес логику от вызовов библиотек и проверяйте её в изоляции. Статические анализаторы так же могут дать представление о возможных косяках в коде. Наконец - opensource - тоже неплохой способ проверить код. Чем больше глаз видит Ваше детище, тем больше багов будет найдено.

Убежденный · 02.11.2015, 00:08

Сообщение от _Valera_

Какие есть программы что бы проверить код на утечку памяти , мусор и другие сюрпризы?

Таких инструментов достаточно немало, каждый со своей особой "кухней".
Детально расписывать не буду, просто накидаю из того, чем сам пользуюсь а
ты решай по каждому пункту, нужен ли он тебе или нет.

1. Проверять код следует на конфигурации Debug, т.к. компилятор вставляет в
нее большее количество проверок и меньше вероятность "прозевать" ошибку,
связанную с управлением памятью.

2. Тестировать лучше на Vista и выше, потому что встроенные механизмы работы с
кучей на этих версиях более чувствительны к ошибкам типа переполнения буфера.
Я рекомендую использовать для тестов как минимум Windows 8 (почему - см. ниже).

3. Использовать Application Verifier.

Application Verifier
https://msdn.microsoft.com/en-... s.90).aspx

Инструмент от Microsoft. Позволяет находить дефекты во время выполнения программы,
например, неправильное использование Win32 API функций, утечки, работа с
невалидными дескрипторами и т.п.

4. Использовать SAL Annotations и встроенный в Visual Studio статический анализатор.

SAL Annotations
https://msdn.microsoft.com/en-... 35402.aspx

Analyzing C/C++ Code Quality by Using Code Analysis
https://msdn.microsoft.com/en-... 82025.aspx

5. Всегда компилировать код с опцией /W4 (выдавать все предупреждения).

Появляющиеся предупреждения в своем коде не подавлять (#pragma warning: disable), а
разбираться с ними.

6. Компилировать код в режиме x64 (всплывают другие ошибки, как правило,
связанные с усечением типов).

7. Использовать отладочную кучу (debug heap).

Поиск ошибок при работе с памятью
https://rsdn.ru/article/vcpp/vcdebug-5.xml

8. Использовать специальные аллокаторы для отслеживания утечек и других дефектов.

Ссылок не привожу, таких аллокаторов полно на каждом углу.

9. Использовать VirtualAlloc/VirtualProtect с искусственно созданным "заграждением".

Отличное средство находить дефекты при работе с буферами.
Суть: выделяете память под буфер с помощью VirtualAlloc, причем так, чтобы сразу за
концом буфера начиналась следующая страница памяти (размер = 4096 байт).
Далее VirtualProtect-ом ставите на эту дополнительную страницу атрибут PAGE_NOACCESS.
Все, теперь если код попытается выйти за пределы буфера хотя бы на один байт, даже просто
на чтение, то немедленно будет выброшено исключение access violation (0xC0000005).
Разумеется, заграждение можно ставить не только за концом буфера, но и с другой стороны.
Дополнительно можно поставить на сам буфер атрибут PAGE_READONLY если, к примеру,
известно, что он используется только на чтение.

10. Запускать тестируемый процесс со специальными ограничениями (Windows 8 и выше).

Есть такая функция:

UpdateProcThreadAttribute
https://msdn.microsoft.com/en-... s.85).aspx

Интересующие опции:

PROCESS_CREATION_MITIGATION_POLICY_HEAP_TERMINATE_ALWAYS_ON

Позволяет более резко реагировать на повреждение кучи.

PROCESS_CREATION_MITIGATION_POLICY_STRICT_HANDLE_CHECKS_ALWA YS_ON

Выбрасывает исключение при попытке использовать невалидный дескриптор.

Можно написать свой test runner, который будет запускать подопытный процесс с
данными флагами, тем самым заставляя его реагировать более жестко на возможные
ошибки данного класса.

11. Применять fuzzing.

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

Есть инструменты типа Microsoft CHESS, LibFuzzer, dfuzz, и другие.

12. Использовать assert-ы, как в compile time, так и в runtime.

Особое внимание уделить проверкам инвариантов. Например, если класс
содержит указатель на данные и их размер, можно вставить в его методы
проверку, что оба они либо равны нулю, либо оба не равны. Если это условие
нарушено, значит, где-то логика работы класса была поломана.

13. Использовать Global Flags (WinDBG).

GFlags
https://msdn.microsoft.com/en-... s.85).aspx

Позволяет включать определенные проверки и режимы работы как для отдельных
приложений, так и для всей системы.

14. Конечно же, писать тесты.

Юнит-тесты, функциональные тесты, стресс-тесты, интеграционные тесты,
тесты совместимости и т.д.

Не могу здесь не порекомендовать Boost.Test и google test / google mock.

15. Проектировать свой софт и писать свой код по принципу "design by contract".

Design by contract
https://en.wikipedia.org/wiki/Design_by_contract

Суть данной идеологии: проектирование на основе "контрактов" между компонентами.
Как только один из компонентов нарушает контракт, приложение останавливает
свою работу и выдает соответствующее сообщение об ошибке.
Каких-либо попыток "угадать, что имел в виду" сбойный компонент, подстроиться под
изменение протокола и продолжить работу и т.п. не предпринимается, реакция на
любой сбой в системе, даже малейший, должна быть максимально резкой.

Профит в том, во-первых, что большинство сбоев при таком подходе будут всплывать
на достаточно ранних стадиях (стоимость исправления данных ошибок невысокая,
так как софт еще не ушел в релиз) и исправляя их, ты сразу повышаешь качество своего софта.
Во-вторых, архитектура ПО и схема взаимодействия между его компонентами сохраняется
достаточно прямолинейной и простой, а это значительно упрощает поддержку кода или
разработку для него всяких расширений.

Понимание этой простой, на вид, идеологии, является очень трудным и приходит с опытом.

16. Использовать сторонние инструменты для статического и динамического анализа.

PVS-Studio
CppDepend
ClocWork
Coverity
Intel Inspector
Relacy Race Detector

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

17. Как средство значительно снизить вероятность появления утечек хорошо помогает RAII.
Все ресурсы (не только память, но и, например, пары функций типа open/close) оборачиваются в
классы-обертки и далее работа ведется только через них. Простой пример - std::string и
std::vector как полная замена строковым функциям и работе с "сырыми" буферами.
Накосячить со сложением строк в std::string гораздо труднее, чем с strcpy/cat.

--------

Все это лишь частные меры, которые дают скромный результат по отдельности, но могут
существенно помочь, когда используются в комплексе. Да, и плохой код, написанный
"размазанно" и архитектурно неграмотно, никакие средства не спасут.

@_Valera_ · 02.11.2015, 01:02 **[ТС]**

Убежденный, спасибо.

@nonedark2008 · 02.11.2015, 02:56

_Valera_, я уже давно использую Intel Parallel.
Есть версия под Win, Linux, OSX.
Inspector помогает определить утечки памяти и ошибки доступа к ней.
VTune позволяет анализировать производительность программы.
Все это добро можно получить бесплатно, являясь студентов, либо украсть.

Тестирование программы С++

Решение

Решение

@_Valera_ 494 / 376 / 136 Регистрация: 27.01.2015 Сообщений: 1,588
		1
	Тестирование программы С++ 01.11.2015, 22:24. Показов 6731. Ответов 8 Метки нет (Все метки) Какие есть программы что бы проверить код на утечку памяти , мусор и другие сюрпризы? Спасибо! 0

@rikimaru2013 2548 / 1207 / 358 Регистрация: 30.11.2013 Сообщений: 3,826
	01.11.2015, 22:29	2
	Сообщение от _Valera_ проверить код на утечку памяти Visual Studio 2015 Сообщение от _Valera_ мусор Нефиг гавнокодить Ну и статический анализатор вон готовит Майерс и КО Сообщение от _Valera_ другие сюрпризы тут нужны тестеры 1

@_Valera_ 494 / 376 / 136 Регистрация: 27.01.2015 Сообщений: 1,588
	01.11.2015, 22:30 [ТС]	3
	Сообщение от rikimaru2013 Visual Studio 2015 не могу, нужно выполнять на 13... Сообщение от rikimaru2013 тут нужны тестеры да, но программист же тоже должен как то протестить... 0

@_Valera_ 494 / 376 / 136 Регистрация: 27.01.2015 Сообщений: 1,588
	01.11.2015, 22:41 [ТС]	5
	Сообщение от rikimaru2013 программисты леньтяи + Да просто пишу сейчас на cocos2dx - там все на указателях, и память вроде как сама потом убирается, но хотелось бы быть уверены что это так, вот и ищу как проверить потери памяти! 0

@Melg 541 / 162 / 79 Регистрация: 23.09.2013 Сообщений: 316
	01.11.2015, 22:48	6
	Сообщение было отмечено _Valera_ как решение Решение _Valera_, На предмет ошибок работы с памятью и потоками, Вам в помощь - valgrind, как не интрузивное средство, а так же address-sanitizer, memory-sanitizer, thread-sanitizer - как интрузивное. Наконец используйте юнит тестирование, отделяйте бизнес логику от вызовов библиотек и проверяйте её в изоляции. Статические анализаторы так же могут дать представление о возможных косяках в коде. Наконец - opensource - тоже неплохой способ проверить код. Чем больше глаз видит Ваше детище, тем больше багов будет найдено. 1

Убежденный Ушел с форума 16448 / 7412 / 1186 Регистрация: 02.05.2013 Сообщений: 11,617 Записей в блоге: 1
	02.11.2015, 00:08	7
	Сообщение было отмечено _Valera_ как решение Решение Сообщение от _Valera_ Какие есть программы что бы проверить код на утечку памяти , мусор и другие сюрпризы? Таких инструментов достаточно немало, каждый со своей особой "кухней". Детально расписывать не буду, просто накидаю из того, чем сам пользуюсь а ты решай по каждому пункту, нужен ли он тебе или нет. 1. Проверять код следует на конфигурации Debug, т.к. компилятор вставляет в нее большее количество проверок и меньше вероятность "прозевать" ошибку, связанную с управлением памятью. 2. Тестировать лучше на Vista и выше, потому что встроенные механизмы работы с кучей на этих версиях более чувствительны к ошибкам типа переполнения буфера. Я рекомендую использовать для тестов как минимум Windows 8 (почему - см. ниже). 3. Использовать Application Verifier. Application Verifier https://msdn.microsoft.com/en-... s.90).aspx Инструмент от Microsoft. Позволяет находить дефекты во время выполнения программы, например, неправильное использование Win32 API функций, утечки, работа с невалидными дескрипторами и т.п. 4. Использовать SAL Annotations и встроенный в Visual Studio статический анализатор. SAL Annotations https://msdn.microsoft.com/en-... 35402.aspx Analyzing C/C++ Code Quality by Using Code Analysis https://msdn.microsoft.com/en-... 82025.aspx 5. Всегда компилировать код с опцией /W4 (выдавать все предупреждения). Появляющиеся предупреждения в своем коде не подавлять (#pragma warning: disable), а разбираться с ними. 6. Компилировать код в режиме x64 (всплывают другие ошибки, как правило, связанные с усечением типов). 7. Использовать отладочную кучу (debug heap). Поиск ошибок при работе с памятью https://rsdn.ru/article/vcpp/vcdebug-5.xml 8. Использовать специальные аллокаторы для отслеживания утечек и других дефектов. Ссылок не привожу, таких аллокаторов полно на каждом углу. 9. Использовать VirtualAlloc/VirtualProtect с искусственно созданным "заграждением". Отличное средство находить дефекты при работе с буферами. Суть: выделяете память под буфер с помощью VirtualAlloc, причем так, чтобы сразу за концом буфера начиналась следующая страница памяти (размер = 4096 байт). Далее VirtualProtect-ом ставите на эту дополнительную страницу атрибут PAGE_NOACCESS. Все, теперь если код попытается выйти за пределы буфера хотя бы на один байт, даже просто на чтение, то немедленно будет выброшено исключение access violation (0xC0000005). Разумеется, заграждение можно ставить не только за концом буфера, но и с другой стороны. Дополнительно можно поставить на сам буфер атрибут PAGE_READONLY если, к примеру, известно, что он используется только на чтение. 10. Запускать тестируемый процесс со специальными ограничениями (Windows 8 и выше). Есть такая функция: UpdateProcThreadAttribute https://msdn.microsoft.com/en-... s.85).aspx Интересующие опции: PROCESS_CREATION_MITIGATION_POLICY_HEAP_TERMINATE_ALWAYS_ON Позволяет более резко реагировать на повреждение кучи. PROCESS_CREATION_MITIGATION_POLICY_STRICT_HANDLE_CHECKS_ALWA YS_ON Выбрасывает исключение при попытке использовать невалидный дескриптор. Можно написать свой test runner, который будет запускать подопытный процесс с данными флагами, тем самым заставляя его реагировать более жестко на возможные ошибки данного класса. 11. Применять fuzzing. Фаззинг - это, упрощенно говоря, подача на вход программы большого набора "мусора", сгенерированного случайно или по определенному шаблону, с целью выявить возможные дефекты (если программа в течение многих часов фаззинга упорно не хочет падать, глючить или зависать, то это хорошая программа). Есть инструменты типа Microsoft CHESS, LibFuzzer, dfuzz, и другие. 12. Использовать assert-ы, как в compile time, так и в runtime. Особое внимание уделить проверкам инвариантов. Например, если класс содержит указатель на данные и их размер, можно вставить в его методы проверку, что оба они либо равны нулю, либо оба не равны. Если это условие нарушено, значит, где-то логика работы класса была поломана. 13. Использовать Global Flags (WinDBG). GFlags https://msdn.microsoft.com/en-... s.85).aspx Позволяет включать определенные проверки и режимы работы как для отдельных приложений, так и для всей системы. 14. Конечно же, писать тесты. Юнит-тесты, функциональные тесты, стресс-тесты, интеграционные тесты, тесты совместимости и т.д. Не могу здесь не порекомендовать Boost.Test и google test / google mock. 15. Проектировать свой софт и писать свой код по принципу "design by contract". Design by contract https://en.wikipedia.org/wiki/Design_by_contract Суть данной идеологии: проектирование на основе "контрактов" между компонентами. Как только один из компонентов нарушает контракт, приложение останавливает свою работу и выдает соответствующее сообщение об ошибке. Каких-либо попыток "угадать, что имел в виду" сбойный компонент, подстроиться под изменение протокола и продолжить работу и т.п. не предпринимается, реакция на любой сбой в системе, даже малейший, должна быть максимально резкой. Профит в том, во-первых, что большинство сбоев при таком подходе будут всплывать на достаточно ранних стадиях (стоимость исправления данных ошибок невысокая, так как софт еще не ушел в релиз) и исправляя их, ты сразу повышаешь качество своего софта. Во-вторых, архитектура ПО и схема взаимодействия между его компонентами сохраняется достаточно прямолинейной и простой, а это значительно упрощает поддержку кода или разработку для него всяких расширений. Понимание этой простой, на вид, идеологии, является очень трудным и приходит с опытом. 16. Использовать сторонние инструменты для статического и динамического анализа. PVS-Studio CppDepend ClocWork Coverity Intel Inspector Relacy Race Detector Сам я данным пунктом не пользуюсь. Реальность такова, что от бесплатных утилит обычно толку практически никакого, а качественно сделанные программы стоят слишком много. 17. Как средство значительно снизить вероятность появления утечек хорошо помогает RAII. Все ресурсы (не только память, но и, например, пары функций типа open/close) оборачиваются в классы-обертки и далее работа ведется только через них. Простой пример - std::string и std::vector как полная замена строковым функциям и работе с "сырыми" буферами. Накосячить со сложением строк в std::string гораздо труднее, чем с strcpy/cat. -------- Все это лишь частные меры, которые дают скромный результат по отдельности, но могут существенно помочь, когда используются в комплексе. Да, и плохой код, написанный "размазанно" и архитектурно неграмотно, никакие средства не спасут. 5

@_Valera_ 494 / 376 / 136 Регистрация: 27.01.2015 Сообщений: 1,588
	02.11.2015, 01:02 [ТС]	8
	Убежденный, спасибо. 0

@nonedark2008 1384 / 1015 / 322 Регистрация: 28.07.2012 Сообщений: 2,801
	02.11.2015, 02:56	9
	_Valera_, я уже давно использую Intel Parallel. Есть версия под Win, Linux, OSX. Inspector помогает определить утечки памяти и ошибки доступа к ней. VTune позволяет анализировать производительность программы. Все это добро можно получить бесплатно, являясь студентов, либо украсть. 1

Опции темы