Valgrind linux как пользоваться

Обновлено: 05.07.2024

Как использовать valgrind для обнаружения утечек памяти в программе?

Пожалуйста, кто-нибудь, помогите мне и опишите шаги для проведения процедуры?

Я использую Ubuntu 10.04 и у меня есть программа a.c , пожалуйста, помогите мне.

Вы используете valgrind для тестирования вашей скомпилированной программы, а не исходного кода. Ответ @RageD, приведенный ниже, правильный, почему вы его не принимаете? Утечка вызвана чем-то, что вы не можете сделать - т.е. свободная выделенная память. Следовательно, Valgrind не может показать вам «где» утечка - только вы знаете, где выделенная память больше не требуется. Однако, сообщая вам, какое распределение не является свободным () d, отслеживая использование этой памяти через вашу программу, вы должны быть в состоянии определить, где она должна освободиться () d. Распространенной ошибкой является выход из функции без освобождения выделенной памяти.

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

Valgrind легко использовать для кода C / C ++, но при правильной настройке его можно использовать и для других языков (см. Это для Python).

Чтобы запустить Valgrind , передайте исполняемый файл в качестве аргумента (вместе с любыми параметрами в программу).

Короче говоря, флаги:

--leak-check=full : "каждая отдельная утечка будет показана подробно"
--show-leak-kinds=all : Показать все «определенные, косвенные, возможные, достижимые» виды утечек в «полном» отчете.
--track-origins=yes : Воспользуйтесь полезным выводом на скорости. Это отслеживает происхождение неинициализированных значений, которые могут быть очень полезны для ошибок памяти. Подумайте об отключении, если Valgrind неприемлемо медленен.
--verbose : Может рассказать вам о необычном поведении вашей программы. Повторите для большего многословия.
--log-file : Запись в файл Полезно, когда вывод превышает пространство терминала.

Наконец, вы хотели бы увидеть отчет Valgrind, который выглядит следующим образом:

Итак, у вас утечка памяти, и Вальгринд не говорит ничего значимого. Возможно, что-то вроде этого:

Давайте посмотрим на код C, который я тоже написал:

Теперь с этой отладочной сборкой Valgrind указывает на точную строку кода, выделяющую утечку памяти! (Формулировка важна: это может быть не совсем то, где находится ваша утечка, а то , что просочилось. След поможет вам найти, где .)

Иногда ваши утечки / ошибки могут быть связаны друг с другом, подобно тому, как IDE обнаруживает, что вы еще не ввели закрывающую скобку. Решение одной проблемы может решить другие, поэтому найдите такую, которая выглядит хорошим виновником, и примените некоторые из этих идей:

Перечислите функции в вашем коде, которые зависят от / зависят от «нарушающего» кода, который имеет ошибку памяти. Следите за выполнением программы (возможно, даже gdb возможно) и ищите ошибки предусловия / постусловия. Идея состоит в том, чтобы отслеживать выполнение вашей программы, сосредотачиваясь на времени жизни выделенной памяти.
Попробуйте закомментировать «нарушающий» блок кода (в пределах разумного, чтобы ваш код все еще компилировался). Если ошибка Valgrind исчезнет, вы найдете ее.

Следите за своими указателями

Как помощник преподавателя, я часто видел эту ошибку. Студент использует локальную переменную и забывает обновить исходный указатель. Ошибка здесь замечает, что realloc фактически может переместить выделенную память куда-нибудь еще и изменить местоположение указателя. Затем мы уходим, resizeArray не сообщая, array->data куда был перемещен массив.

Неверная запись

Обратите внимание, что Valgrind указывает нам на закомментированную строку кода выше. Массив размером 26 индексируется [0,25], поэтому *(alphabet + 26) является недопустимой записью - это выходит за пределы. Недопустимая запись является распространенным результатом ошибок «один за другим». Посмотрите на левую сторону вашей операции присваивания.

Неверное чтение

Valgrind указывает нам на прокомментированную строку выше. Посмотрите на последнюю итерацию здесь, которая есть
*(destination + 26) = *(source + 26); . Тем не менее, *(source + 26) снова выходит за пределы, так же, как и недопустимая запись. Недопустимые чтения также являются частым результатом ошибочных ошибок. Посмотрите на правую сторону вашей операции присваивания.

Как я узнаю, когда утечка моя? Как мне найти утечку, когда я использую чужой код? Я нашел утечку, которая не моя; я должен что-то сделать? Все законные вопросы. Во-первых, 2 реальных примера, которые показывают 2 класса общих встреч.

Янссон : библиотека JSON

Это простая программа: она читает строку JSON и анализирует ее. При создании мы используем библиотечные вызовы, чтобы выполнить анализ для нас. Янссон динамически распределяет необходимые распределения, поскольку JSON может содержать собственные вложенные структуры. Однако это не означает, что мы decref или «освобождаем» память, данную нам от каждой функции. На самом деле, этот код, который я написал выше, выбрасывает «Неверное чтение» и «Неверное чтение». Эти ошибки исчезают, когда вы убираете decref строку для value .

Зачем? Переменная value считается «заимствованной ссылкой» в API Jansson. Янссон следит за своей памятью для вас, и вам просто нужно, чтобы decref структуры JSON были независимы друг от друга. Урок здесь: прочитайте документацию . В самом деле. Иногда это трудно понять, но они говорят вам, почему это происходит. Вместо этого у нас есть существующие вопросы об этой ошибке памяти.

SDL : библиотека графики и игр

Что не так с этим кодом ? Это постоянно пропускает

212 КиБ памяти для меня. Найдите минутку, чтобы подумать об этом. Мы включаем SDL и затем выключаем. Ответ? Нет ничего плохого.

Поначалу это может показаться странным . По правде говоря, графика грязная, и иногда вы должны принять некоторые утечки как часть стандартной библиотеки. Урок здесь: вам не нужно подавлять каждую утечку памяти . Иногда вам просто нужно подавить утечки, потому что это известные проблемы, с которыми вы ничего не можете сделать . (Это не мое разрешение игнорировать ваши собственные утечки!)

Ответы в пустоту

Как я узнаю, когда утечка моя?
Это. (99% уверен, в любом случае)

Как мне найти утечку, когда я использую чужой код?
Скорее всего, кто-то другой уже нашел это. Попробуйте Google! Если это не поможет, используйте навыки, которые я дал вам выше. Если это не помогло, и вы в основном видите вызовы API и немного собственной трассировки стека, см. Следующий вопрос.

Я нашел утечку, которая не моя; я должен что-то сделать?
Да! У большинства API есть способы сообщать об ошибках и проблемах. Используй их! Помогите вернуть инструменты, которые вы используете в своем проекте!

Спасибо, что остался со мной так долго. Я надеюсь, что вы чему-то научились, так как я пытался склониться к широкому кругу людей, приходящих к этому ответу. Надеюсь, вы спросили кое-что еще: как работает распределитель памяти в C? Что такое утечка памяти и ошибка памяти? Чем они отличаются от сегфо? Как работает Valgrind? Если у вас есть что-то из этого, пожалуйста, подпитывайте свое любопытство:

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

Данная статья содержит краткое описание принципов работы с valgrind и использования различных его модулей. Данное описание соответствует valgrind версии 3.3. Дополнительную информацию о работе с valgrind вы можете найти на его сайте, который содержит руководства разного уровня сложности, начиная от достаточно легкого Quick Start, и заканчивая подробными руководством пользователя и техническим описанием системы.

Архитектура Valgrind

Valgrind имеет модульную архитектуру, и состоит из ядра, которое выполняет эмуляцию процессора, а конкретные модули выполняют сбор и анализ информации, полученной во время выполнения кода на эмуляторе. Valgrind работает под управлением ОС Linux на процессорах x86, amd64, ppc32 и ppc64 (стоит отметить, что ведуться работы по переносу Valgrind и на другие ОС), при этом существуют некоторые ограничения, которые потенциально могут повлиять на работу исследуемых программ. 1

В поставку valgrind входят следующие модули-анализаторы:

memcheck основной модуль, обеспечивающий обнаружение утечек памяти, и прочих ошибок, связанных с неправильной работой с областями памяти — чтением или записью за пределами выделенных регионов и т.п. cachegrind анализирует выполнение кода, собирая данные о (не)попаданиях в кэш, и точках перехода (когда процессор неправильно предсказывает ветвление). Эта статистика собирается для всей программы, отдельных функций и строк кода callgrind анализирует вызовы функций, используя примерно ту же методику, что и модуль cachegrind. Позволяет построить дерево вызовов функций, и соответственно, проанализировать узкие места в работе программы. massif позволяет проанализировать выделение памяти различными частями программы helgrind анализирует выполняемый код на наличие различных ошибок синхронизации, при использовании многопоточного кода, использующего POSIX Threads.

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

Начало работы с valgrind

В настоящее время valgrind входит в состав практически всех дистрибутивов Linux, и только в редких случаях требуется его установка вручную, поэтому я пропущу описание этого процесса 2 .

Работа с valgrind достаточно проста — его поведение полностью управляется опциями командной строки, а также не требует специальной подготовки программы, которую вы хотите проанализировать (Хотя все-таки рекомендуется пересобрать программу с отладочной информацией и отключенной оптимизацией используя флаги компиляции -g и -O0 ). Если программа запускается командой " программа аргументы ", то для ее запуска под управлением valgrind, необходимо в начало этой командной строки добавить слово valgrind , и указать опции, необходимые для его работы. Например, так:

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

По умолчанию, valgrind запускает модуль memcheck, однако пользователь может указать какой модуль должен выполняться с помощью опции --tool , передав в качестве аргумента имя нужного модуля, например, вот так:

Стоит отметить, что часто используемые опции можно задать один раз, используя глобальный файл конфигурации (

/.valgrindrc ), так что вам не придется их набирать при каждом запуске valgrind.

Общие опции запуска программы

Некоторые опции командной строки являются общими для всех модулей. К наиболее часто используемым опциям можно отнести 3 :

Опции управления обработкой ошибок

Пользователь valgrind имеет достаточно большой набор опций, предназначенных для управления процессом обработки ошибок — начиная от опций управления форматом вывода, и заканчивая опциями, задающими размер стека.

Пользователь также может управлять тем, сколько и каких ошибок будет выведено в отчет. Для этого имеется опция --error-limit ( yes или no , по умолчанию yes ), которая позволяет ограничить отчет выводом 1000 различных ошибок. Если пользователь не ограничивает вывод ошибок, то это также сказывается на производительности.

Кроме того, пользователь может управлять тем, какие ошибки будут выдаваться в отчет, а какие нет. Это делается с помощью задания специальных директив (suppressions), которые записываются в файлы, имена которых можно передать с помощью опции --suppressions . В поставке valgrind есть файл (обычно это /usr/lib/valgrind/default.supp ), в котором перечислены известные ошибки glibc, но кроме того, пользователь может изготовить собственный файл, для чего можно использовать опцию --gen-suppressions , которая будет запрашивать пользователя, нужно ли сгенерировать директиву для данной ошибки, или нет.

Пользователь также имеет возможность запуска отладчика при нахождении ошибок. Для этого существует опция --db-attach ( yes или no , по умолчанию no ), при использовании которой у пользователя будет запрашиваться разрешение на запуск отладчика. Опции для запуска отладчика могут быть указаны с помощью опции --db-command , но значений по умолчанию вполне достаточно для большинства случаев.

Поиск утечек памяти

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

--leak-check включает (значение yes , summary или full ) или отключает (значение no ) функцию обнаружения утечек памяти. Стоит отметить, что при использовании значения summary , memcheck выдает лишь краткую информацию об утечках памяти, тогда как при других значениях, кроме сводной информации, будет выдаваться еще и информация о месте, в котором происходит эта утечка памяти. --leak-resolution (возможные значения low , med или high ) указывает способ сравнения стека вызовов функций. При значениях low и med , в сравнении используются два или четыре последних вызова, соответственно, а при high , сравнивается полный стек вызова. Эта опция влияет лишь на способ представления результатов поиска ошибок. --undef-value-errors ( yes или no ) определяет, будут ли показывать ошибки об использовании не инициализированных значений.

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

Интерпретация полученных результатов

Существует несколько видов ошибок, обнаруживаемых модулем memcheck. Ошибки чтения и записи за пределами выделенной памяти (и еще несколько видов ошибок) выдаются сразу, в процессе работы программы. А ошибки, ведущие к утечкам памяти, выдаются valgrind'ом после завершения работы анализируемой программы. Формат выдачи этих ошибок немного отличается, поэтому они будут описаны по отдельности.

Каждая строка в выводе valgrind имеет префикс вида

где число обозначает идентификатор запущенного процесса.

Ошибки работы с памятью

В ходе своей работы, модуль memcheck определяет несколько видов ошибок работы с памятью:

чтение или запись по неправильным адресам памяти — за границами выделенных блоков памяти и т.п.
использование не инициализированных значений, в том числе и для переменных выделяемых на стеке
ошибки освобождения памяти, например, когда блок памяти уже был освобожден в другом месте
использование "неправильной" функции освобождения памяти, например использование delete для памяти, выделенной с помощью new []
передача некорректных параметров системным вызовам, например указание неправильных указателей для операций чтения из буфера, указанного пользователем
пересечение границ блоков памяти при использовании операций копирования/перемещения данных между двумя блоками памяти

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

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

Нахождение утечек памяти

При окончании работы программы valgrind выдает сводную таблицу, описывающую количество найденных ошибок, а также выделение памяти в программе, например:

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

Definitely lost означает, что valgrind нашел область памяти, на которую нет указателей, т.е. программист не освободил память, при выходе указателя за область видимости. Possibly lost показывает, что найден указатель, указывающий на часть области памяти, но valgrind не уверен в том, что указатель на начало области памяти до сих пор существует (это может происходить в тех случаях, когда программист вручную управляет указателями). Still reachable обычно означает, что valgrind нашел указатель на начало не освобожденного блока памяти, что во многих случаях связано с выделением глобальных переменных и т.п. вещей. Обычно эта информация показывается только при указании опции --show-reachable со значением yes .

Между двумя этими таблицами выдаются данные по каждой из найденных ошибок работы с памятью, вида:

Первой строкой идет описание ошибки, вместе с указанием номера блока в списке потенциально потерянных блоков памяти, а также размером "потерянного" блока памяти. "Важность" ошибки соответствует описанию в итоговой таблице. После строки описания, приводится стек вызовов функций, которые привели к возникновению "потерянного" блока памяти. Этот список достаточно подробен для того, чтобы обнаружить точное место возникновения данной утечки памяти.

Полезные советы при работе с memcheck

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

Профилирование программ

Профилирование программ может осуществляться с помощью двух модулей — callgrind и cachegrind. Каждый из них собирает разную информацию. При этом нельзя полагаться на результаты работы только одного из модулей, лучше проводить поиск "узких" мест в программах на основе анализа вывода каждого из модулей.

cachegrind

Модуль cachegrind проводит сбор статистики по попаданию в кэш первого и второго уровней процессора при выполнении операций чтения и записи данных и инструкций программ, а также статистику по работе модуля предсказания ветвлений в программах. По умолчанию, сбор статистики о предсказании ветвления инструкций (branch prediction) не проводится, и если вы хотите получить эти данные, то вы должны указать опцию --branch-sim со значением yes . Кроме этого, пользователь имеет возможность указания дополнительных опций, например, задающих размеры кэшей и т.п.

Результаты собранные данным модулем по умолчанию выводятся в файл с именем cachegrind.out.<pid> ( pid — идентификатор процесса). Если вы хотите использовать другое имя файла, то можете воспользоваться опцией --cachegrind-out-file .

После завершения программы, valgrind выдаст таблицу с суммарными данными, собранными во время выполнения программы, например:

в которой перечислены данные по выборке инструкций и данных процессором. А в файл cachegrind.out (достаточно большой даже для очень простых программ), попадут детальные данные, которые можно использовать для поиска "узких" мест в программах. Удобным средством анализа является программа kcachegrind, но и в поставке valgrind есть программа cg_annotate , которая позволяет проводить анализ производительности программ 4 .

Для получения данных, в качестве параметров программы cg_annotate указывают имя файла с результатами, собранными cachegrind, а также (опционально) список файлов с исходными текстами, которые будут аннотированы по результатам работы cg_annotate . Чтобы не указывать все файлы с исходными текстами вручную, cg_annotate принимает опцию --auto со значением yes , и автоматически ищет нужные файлы (с помощью опции -I можно указать каталоги, в которых должен производиться поиск файлов).

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

callgrind

Данный модуль позволяет собрать информацию о дереве вызова функций в программе. По умолчанию он собирает данные о количестве выполненных инструкций, зависимостях между вызывающей и вызываемой функциями и количество вызовов конкретных функций. Кроме того, можно включить эмуляцию кэшей, аналогичную cachegrind, что позволит собрать данные о доступе к памяти.

Данные собранные модулем выводятся в файл callgrind.out.<pid> , который затем может быть проанализирован с помощью программ kcachegrind или callgrind_annotate (входящей в поставку valgrind).

callgrind_annotate выводит на экран данные о выполнении различных функций, и может представлять их в различном виде, в зависимости от указанных опций. Также как и для cg_annotate , можно указать опцию --auto , чтобы избежать указания файлов с исходными текстами вручную.

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

Анализ выделения памяти в программе

Для анализа выделения памяти в программах используется модуль massif. Он собирает сведения не только о размерах блоков, выделяемых программой, но также и о том, сколько дополнительной памяти потребуется для хранения служебной информации.

После завершения программы под управлением massif, valgrind выдает краткую сводку использования памяти, а подробные данные выводятся в файл massif.out.<pid> . Для анализа этих данных может использоваться программа ms_print , входящая в поставку valgrind. Эта программа может выдавать данные в виде графиков, демонстрирующих выделение памяти в программе в процессе работы, например вот так:

Пользователь может использовать дополнительные опции massif для управления частотой снятия снапшотов, их количеством, списком функций, для которых будет производиться анализ (можно, например, отслеживать только new или malloc ) и т.п.

Поиск ошибок синхронизации

За поиск этого класса ошибок отвечает модуль helgrind. Он позволяет найти ошибки синхронизации в программах на языках C, C++ & Fortran, использующих POSIX Thread API. Helgrind помогает обнаружить следующие классы ошибок:

потенциальные блокировки (deadlocks), возникающие из-за неправильного порядка выставления блокировок
повреждение данных (data races) из-за неправильных, или отсутствующих блокировок на доступ к памяти
неправильное использование функций POSIX API. Этот класс ошибок включает в себя разные ошибки, например рекурсивное блокирование не рекурсивного мутекса, освобождение памяти, хранящей блокировку (мутекс) и т.д.

Helgrind позволяет найти эти ошибки за счет отслеживания состояния каждого из байтов памяти, используемой программой, а также за счет мониторинга различных событий, связанных с выполнением нитей (threads) — их создания и завершения, получение и освобождения блокировок и т.п.

Формат вывода информации немного похож на формат вывода ошибок модулем memcheck:

В данном примере helgrind указывает на возможное повреждение данных при одновременном выводе данных на экран несколькими нитями исполнения. Кроме стека вызова функций, приводящего к ошибке, также выдается состояние памяти до и после возникновения ошибки (old и new state), а также причина возникновения ошибки (в нашем случае — отсутствие блокировок для данного участка памяти).

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

Дополнительные программы для работы с valgrind

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

Программа alleyoop позволяет работать с valgrind, используя графический интерфейс пользователя. Она позволяет выбрать нужную утилиту, и запустить valgrind с нужными опциями, а затем проанализировать вывод valgrind, и обеспечить навигацию по коду, который вызывает ошибки. В настоящее время поддерживается работа с модулями memcheck, helgrind и cachegrind.
Для визуализации данных, полученных от модулей callgrind и cachegrind, существует программа — kcachegrind, которая отображает полученные данные, и позволяет выполнять навигацию по исходному коду программы. Программа позволяет отображать собранные данные различными способами — в виде таблиц, карт и графов вызова функций. Пример отображения этих данных вы можете видеть на рисунке.

1. Хорошее описание архитектуры Valgrind и принципов его работы можно найти в статье Valgrind: A Framework for Heavyweight Dynamic Binary Instrumentation

2. Интересующиеся, могут найти описание процесса сборки и установки в руководстве пользователя valgrind.

3. Для задания опций используется стандартная форма. Некоторые опции могут иметь одно-буквенные сокращения, и если они имеют аргументы, то аргументы задаются через пробел после указания соответствующей опции. Для опций, с полным названием, таких как <code>--log-file , аргументы указываются сразу после опции, используя знак = в качестве разделителя имени и значения.

4. В руководстве пользователя valgrind есть описание формата данных, выводимых модулем cachegrind, так что пользователь может писать и свои анализаторы.

Работа с Valgrind

Установка, общая информация

Средство отладки Valgrind входит в состав большинства дистрибутивов Linux. Установка в Ubuntu и Debian:

Valgrind является фреймворком, на основе которого созданы несколько инструментов (tools). Некоторые из них предназначены для поиска ошибок связанных с многопоточносью (Helgrind), другие для оптимизации программ (Cachegrind).

Нас будет в первую очередь интересовать memcheck - инструмент для поиска ошибок, возникающих при работе с памятью. При запуске Valgrind без явного указания инструмента будет запущен именно memcheck.

Подготовка программы для отладки

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

Компиляция с выводом отладочной информации при помощи GCC

Ключи компилятора GCC, отвечающие за отладочную информацию, начинаются с -g. . Например просто ключ -g добавляет в файл "базовую" отладочную информацию. Для вывода подробной отладочной информации, в т.ч. расширений предназначенных для отладчика GDB используется ключ -ggdb3 :

Отладочная информация, оптимизации и поведение программы

Важно понимать, что при наличии в программе ошибок (неопределённого поведения) оптимизации компилятора могут изменять наблюдаемое поведение программы. Например, программа может создавать видимость абсолютно корректной работы при оптимизации с уровнем -O1 , но "падать" с уровнем -O3 . Эта неприятная особенность языков C и С++ является "расплатой" за саму возможность применять некоторые важные оптимизации (т.е. за возможность достичь высокой производительности). Я постараюсь написать об этом отдельный пост.

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

Важная особенность компиляции с отладочной информацией: вывод отладочной информации не может влиять на поведение программы, т.е. программа скомпилированная с ключом -g и без него выполняет одни и те же инструкции процессора.

Запуск программы под Valgrind-ом

Для запуска программы под Valgrind-ом вы просто указываете список параметров Valgrind-а, затем название вашей программы, и затем параметры, которые вы хотите передать вашей программе. Пример:

Данная команда запустит valgrind с параметром --leak-check=yes (поиск утечек памяти), который с свою очередь запустит программу my-program с параметрами -o out.txt , в поток stdin будет перенаправлен файл in.txt .

Если запустить Valgrind как valgrind ./my-program --leak-check=yes , то параметр --leak-check=yes будет передан программе my-program, а не valgrind

valgrind --trace-children=yes ./test-my-program.sh

Valgrind значительно замедляет работу программы (на порядок и более), это несколько сужает область его применения

Для поиска утечек памяти следует использовать ключ --leak-check=yes , ошибки доступа к памяти диагностируются по умолчанию (дополнительных параметров не требуется).

Виды ошибок и интерпретация результата

Общий формат вывода, бэктрейс

Рассмотрим по отдельности элементы, из которых оно состоит.

В столбце слева мы видим число ==72250== . Это идентификатор процесса (pid). Если вам вдруг потребуется отлаживать сразу несколько взаимодействующих между собой процессов (хотя в нашем курсе такая необходимость вряд ли возникнет), он поможет вам понять, в каком именно из процессов произошла ошибка.
Далее, в первой строке указан вид ошибки (возможные виды ошибок будут рассмотрены далее). В данном случае Valgrind указывает нам, что произошла ошибка доступа к памяти: попытка записать 8 байт в область, к которой корректно написанная программа не должна обращаться.
Все последующие строки представляют собой бэктрейс.

Бэктрейс (backtrace, называемый также stack trace, иногда call string, последовательность вызовов) - это способ точно указать в какой именно точке программы произошло интересующее нас событие (в нашем случае, ошибка). Проблемное место - файл bitmap.h , строка 333 (строки нумеруются с 1, этому соглашению следуют все инструменты для работы с кодом) в функции bitmap_initialize_stat . Указан также адрес в памяти, 0x10200988 (адрес мог бы понадобиться, если по какой-то причине не удалось установить соответствие с исходным кодом). Информации о том, что ошибка произошла в функции bitmap_initialize_stat могло бы быть вполне достаточно, чтобы устранить ошибку, но если бы на этом месте оказалась функция memcpy , то вряд ли бы такая информация была полезной: в большой программе могут быть сотни и тысячи вызовов многих частых функций. Поэтому Valgrind показывает нам, откуда была вызвана функция bitmap_initialize_stat , а именно, из функции bitmap_obstack_alloc_stat (в файле bitmap.c , строка 286), а та, в свою очередь была вызвана из функции df_analyze и так далее, до функции main которая вызвала метод main класса toplev в файле toplev.c .

Чтение неинициализированной памяти

Попробуем скомпилировать и запустить следующую программу:

Как видим, в ней выделяется массив data, в первые 3 элемента которого по замыслу разработчика записываются символы a , b и c соответственно. В строке 9 (номера строк указаны в комментарии справа) допущена опечатка, из-за которой символ c записывается во второй элемент, а не в третий. Если запустить программу под Valgrind-ом, мы увидим следующее:

Выход за границу массива

Теперь рассмотрим другой пример:

Использование памяти после освобождения

Изменим функцию main в предыдущем примере следующим образом:

Из него видно, что в функции vfprintf, в которую мы попали, вызвав printf в строке 19, произошло чтение из ранее освобождённой области памяти: адрес 0x51de040 находится непосредственно в начале (0 bytes inside) блока длиной 13 байт, освобождённого в строке 18.

Ещё одна ошибка:

В строке 20 мы пытаемся освободить память, которая уже была освобождена ранее. Кстати, эту ошибку часто способен обнаружить аллокатор памяти в библиотеке glibc. Если мы запустим программу без Valgrind, то увидим следующее:

Теперь изменим функцию main в нашем примере следующим образом:

Если запустить программу под Valgrind-ом с ключом --leak-check=yes , то Valgrind сообщит нам о том, какие именно блоки памяти не были освобождены:

Valgrind обнаруживает в ней одну ошибку:

Хотя на самом деле в ней присутствует выход за границы массивов src и dest .

Лирическое отступление. Обнаружение выхода за границы массива на этапе компиляции

Ошибки, имеющися в приведённом примере может обнаружить оптимизирующий компилятор. Скомпилируем программу с оптимизацией:

GCC выдаёт следующие предупреждения:

Clang (вплоть до последней на сегодняшний день версии 3.7) в этой ситуации уступает GCC. Он не способен обнаружить проблем в этой программе. Это связано с принципиально различающимися подходами GCC и Clang к диагностике: Clang (это т.н. фронтэнд компилятора) анализирует программу, переводит её в промежуточное представление и одновременно пытается диагностировать ошибки. Далее промежуточное представление оптимизируется бэкэндом (LLVM), на этом этапе диагностика ошибок не производится. В GCC же диагностика некоторых ошибок производится бэкэндом, за счёт этого те механизмы (анализ количества итераций цикла), которые используются для оптимизации программы удаётся применить также для диагностики ошибок.

[Linux] Подробный набор инструментов Valgrind (2): Начало работы

Во-первых, используйте valgrind

1, установка

Установка очень проста:
sudo apt-get install valgrind

2, с использованием

Запустите valgrind -h, чтобы увидеть подробное использование. Формат команды следующий:

Наиболее важным параметром является -tool, который решает, какой инструмент Valgrind запустить.
Например, используя инструмент проверки памяти Memcheck для запуска команды "ls -l", формат команды выполнения выглядит следующим образом:

Memcheck является настройкой по умолчанию, поэтому, если вы хотите использовать ее, вы можете опустить параметр –tool, например:

3, принцип

Затем тестируемая программа будет работать на «синтетическом процессоре», предоставленном ядром Valgrind. Когда новый код выполняется впервые, ядро Valgrind передает программный код выбранному инструменту. Инструмент добавляет сюда свой собственный код обнаружения и возвращает результаты ядру, которое координирует непрерывное выполнение этого кода обнаружения.

Количество добавленного кода обнаружения значительно различается в зависимости от инструмента. Memcheck добавил код, чтобы проверять каждый доступ к памяти и каждое вычисленное значение, делая его в 10-50 раз медленнее, чем собственный. Для Nulgrind (самого маленького инструмента) вообще не добавляется никаких инструментов, и он работает в 4 раза медленнее, чем эта машина.

Valgrind имитирует каждую инструкцию, выполняемую программой. Поэтому активный инструмент проверяет не только код в приложении, но и весь код, который поддерживает библиотеки динамических ссылок (включая библиотеку C, графическую библиотеку и т. Д.).

Если вы используете инструмент обнаружения ошибок, Valgrind может обнаруживать ошибки в системных библиотеках, таких как библиотеки GNU C или X11. Хотя эти ошибки вас не интересуют, вы не можете контролировать код. Следовательно, Valgrind позволяет выборочно подавлять ошибки, записывая их в «файл подавления» (который будет обсуждаться позже), который Valgrind начинает читать (то есть ошибки в системных библиотеках не печатаются). Механизм сборки Valgrind выбирает подавление по умолчанию, чтобы обеспечить разумное поведение для операционных систем и библиотек, обнаруженных на компьютере. Чтобы было проще писать подавления, вы можете использовать опцию --gen-suppressions = yes. Это говорит Valgrind распечатывать подавление для каждой сообщаемой ошибки, которая затем может быть скопирована в файл подавления.

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

4, небольшое объяснение опций gcc при компиляции программы

Лучше всего использовать отладочную версию (gcc -g), чтобы в напечатанной информации указывались соответствующие строки кода для информации об ошибке и анализа;
Если это C ++, лучше рассматривать встроенные функции как обычные функции (gcc -fno-inline), чтобы легче было видеть цепочку вызовов функций, что помогает уменьшить большой C ++ Путаница при навигации в приложении;
Не используйте оптимизации (gcc -O2 или gcc-O1 и т. д.), это приведет к тому, что Memcheck неправильно сообщит об ошибках неинициализированных значений или об ошибках неинициализированных значений;
При компиляции лучше отображать все предупреждения (gcc -Wall)

Читайте также: