Майкл Джонсон - Разработка приложений в среде Linux. Второе издание

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

В отличие от mcheck(), в mtrace()нет соответствующей библиотеки для компоновки. Это не проблема, поскольку трассировку можно осуществлять в gdb. Однако для включения трассировки с помощью mtrace()должна быть установлена переменная окружения MALLOC_TRACEв допустимое имя файла; это может быть либо имя существующего файла, в который процесс может вести запись, либо имя нового файла, который процесс создаст и будет в него записывать.

$ MALLOC_TRACE=mtrace.log gdb broken

...

(gdb) breakmain

Breakpoint 1 at 0x80483f4: filebroken.c, line 14.

(gdb) command 1

Type commands for when Breakpoint 1 is hit, one per line.

End with a line saying just "end".

>call mtrace()

>continue

>end

(gdb) run

Starting program: /usr/src/lad/code/broken

Breakpoint 1, main() at broken.с:47

47 return broken();

$1 = 0

1: 12345

2: 12345678

3: 12345678

4: 12345

5: 12345

6: 12345

7: 12345

Program exited normally.

Программа завершена нормально.

(gdb) quit

$ ls -l mtrace.log

-rw-rw-r-- 1 ewt ewt 220 Dec 27 23:41 mtrace.log

$ mtrace ./broken mtrace.log

Memory not freed:

He освобождена память:

----------------------

Address Size Caller

Адрес Размер Место вызова

0x09211378 0x5 at /usr/src/lad/code/broken.с:20

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

Возможности mtrace()в glibcдостаточно неплохие, но профилировщик распределения памяти mpr(http://www3.telus.net/taj_khattra/mpr.html) в некоторых аспектах более прост в использовании и содержит более совершенные сценарии для обработки выходных журнальных файлов.

Первый шаг в применении mpr(после сборки кода с включенной отладочной информацией [10] Для большей переносимости многие из средств mpr анализа журнала используют gdb для связывания адреса с соответствующим местом в исходном коде. Чтобы это работало, программа должна содержать отладочную информацию. ) состоит в установке переменной окружения MPRFI, которая указывает mpr, с какой командой связывать журнал (если переменная не установлена, журнал не генерируется). Для небольших программ MPRFIустанавливается подобно cat >mpr.log. Для программ покрупнее MPRFIможно существенно сэкономить пространство за счет сжатия журнального файла во время его записи, установив MPRFIв gzip -1 >mpr.log.gz.

Самый легкий способ — воспользоваться сценарием mprдля запуска программы; если MPRFIеще не установлена, она получит значение gzip -1 >log.%p.gz, что приведет к созданию журнального файла с идентификатором процесса отлаживаемой программы и загрузке библиотеки mpr. В результате сборка программы не понадобится. Ниже показан пример создания журнального файла для исправленной версии нашей тестовой программы.

$ MPRFI="cat >mpr.log" mpr ./broken

1: 12345

2: 12345678

3: 12345678

4: 12345

5: 12345

6: 12345

7: 12345

$ ls -l mpr.log

-rw-rw-r-- 1 ewt ewt 142 May 17 16:22 mpr.log

После создания журнального файла доступны многие средства для его анализа. Все эти программы получают журнальный файл mpr в качестве стандартного ввода. Если вывод из этих средств содержит числа в тех местах, где ожидаются имена функций (возможно, с предупреждением вроде "cannot map pc to name" ("невозможно отобразить программный счетчик на имя")), проблема может быть связана с версией утилиты awk, которую использует mpr. В документации mprдля достижения лучших результатов рекомендуется экспортировать переменную окружения MPRAWKдля выбора mawkв качестве версии awk: export MPRAWK='mawk -W sprintf=4096'. Кроме того, сбить с толку mpr может еще и рандомизация стека, которая обеспечивается функциональностью ядра "Exec-shield"; исправить положение можно за счет использования команды setarch, отключающей Exec-shield во время работы исследуемой программы и во время работы фильтров mpr: setarch i386 mpr программа и setarch i386 mprmap ...

В конечном итоге для некоторых стековых фреймов mprможет не найти символическое имя; в этом случае просто проигнорируйте их.

Теперь, когда известно об анализаторах журнальных файлов, очень просто найти утечки памяти в нашей тестовой программе. Для этого достаточно воспользоваться командой mprleak mpr.log | mprmap -l ./broken(что эквивалентно mprmap -l ./broken mpr.log | mprleak) и в результате обнаружить утечку памяти в строке 20.