Страницы

Поиск по вопросам

пятница, 12 июля 2019 г.

Вопрос по работе Valgrind

Всем добрый день! Пытаюсь разобраться с Valgrind (Memcheck), возникла пара вопросов: (Отредактирован) При запуске приложения под Valgrind функция sigprocmask() завершается с ошибкой, в то время, как при обычном запуске работает и возвращает валидное значение. С чем это может быть связано? Если кто может, объясните, пожалуйста, на пальцах, что означает "still reachable" в результатах работы Valgrind? Из прочтенного - это еще доступные ресурсы, которые могут быть освобождены, однако, если учесть, что демон досрочно завершился, почему они доступны? Это могут быть переменные, объявленные в данном модуле как extern? Заранее извиняюсь, если вопросы покажутся праздными, осваиваю Valgrind c наскока в короткий срок, хочется разобраться. Не откажусь от ссылок на подробную информацию, освещающую эти вопросы.


Ответ

Приложение должно работать, как обычно, но медленнее. Но довольно часто при использовании valgrind проявляют себя ошибки, которые в обычной программе остались незамеченными (из-за случайности). Например, попытка использования памяти, которую только что освободили. still reachable означает, что к моменту завершения программы вы не сделали delete для каких-то указателей, но сами указатели еще остались (т.е. можно было освободить память). Это может быть из-за того, что ваша программа упала, а не завершилась нормально Добавлено: Не имеет значения, каким этот показатель будет после завершения программы, потому что вся выделенная память все равно вернется операционной системе. Но то, что где-то в программе накопилась неучтенная память -- не очень хорошо. Пример: демон раз в N секунд выполняет какое-то действие. Допустим, он должен хранить историю последних десяти действий. Тогда у него будет такой алгоритм работы: Что-то сделать. Если записей больше десяти, удалить одну Добавить запись о текущем действии в историю Если случайно сделать ошибку во втором пункте, история (и вообще, количество выделенной программе памяти) будет бесконечно расти. Но вся эта память будет still reacable, потому что, теоретически, ее можно освободить. Я бы начал не с этого. Лучше сначала написать небольшой скрипт, который будет раз в N секунд читать данные (в основном, VmRSS) из /proc/[pid]/status и дал бы программе поработать какое-то время. Потом строите график, и все сразу становится видно: если портебление памяти растет, надо браться за valgrind и искать причины, если достаточно стабильно -- фиг с ним.

Комментариев нет:

Отправить комментарий