LINUX.ORG.RU
Форум — Development  

[C/C++] трассировка работы с памятью


0

0

есть необходимость отслеживать все операции выделения/освобождения памяти в адресном пространстве процесса (без shared memory) в реальном времени - включая область данных, bss, стек и кучу

для кучи неплохим вариантом получается отладочный *alloc, но он ничего не говорит об остальных сегментах; обзорную информацию хорошо показывает memstat, но в нём нет возможности логировать частные операции; valgrind'овский memcheck, опять же, не исследует ничего кроме кучи. очень хочется чего-нибудь вроде карты памяти процесса в QNX Momentics, но для Linux

в принципе можно обрабатывать вывод strace на предмет интересных ядерных вызовов, но так значительно сложней анализировать результирующую информацию (backtrace как в случае отладочного *alloc'а уже не получить, тип под который выделяется память - тоже). gdb позволяет много чего узнать о памяти процесса, но вот трассировки в реальном времени я у него найти не смог

кто что может посоветовать? какой велосипед я не заметил?

★★★★★

Ответ на: комментарий от babka1440

> man strace

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

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от tailgunner

>LD_PRELOAD, переопределяющий mmap и sbrk?

вот над этим подумаю, спасибо

>Скриптованный gdb?

можно ссылку на описание того, в какую сторону его хоть скриптовать? в смысле, какие-нибудь примеры подобного использования. shame on me, никогда не скриптовал gdb

jtootf ★★★★★
() автор топика
Ответ на: комментарий от guest-3484-2009

>Языка C/C++ не существует

очень ценное замечание. указанная выше задача мне нужна в контексте C++, но если есть решение для ANSI C - я буду не против

jtootf ★★★★★
() автор топика

>есть необходимость отслеживать все операции выделения/освобождения памяти в адресном пространстве процесса (без shared memory) в реальном времени - включая область данных, bss, стек и кучу

В области данных и bss память не выделяется и не освобождается. С кучей все ясно, а страницы для стека только выделяются (по мере надобности), но не освобождаются. Таким образом задача сводится только к мониторингу выделения страниц для стека. Ну тут кривой вариант смотреть /proc/pid/maps on-line или писать модуль к ядру и отлавливать page fault.

Chumka ★★★
()
Ответ на: комментарий от jtootf

>> Скриптованный gdb?

> можно ссылку на описание того, в какую сторону его хоть скриптовать?

Сразу скажу - я когда-то давно пытались использовать эту фишку для трассировки программ, но забил (отладочная печать оказалась легче). Общий принцип - ставится брякпойнт, на который вешается gdb-скрипт, в моем случае он просто печатал переменные. Тогда это было описано в info gdb, которого почему-то нет в Lenny O_o

Гугель сказал это: http://sources.redhat.com/gdb/current/onlinedocs/gdb_toc.html#SEC_Contents

В частности. 5.1.7 и гл. 21.

Походу, там даже есть Python-интерфейс к внутренностям gdb, так что есть где порезвиться O_o

> в смысле, какие-нибудь примеры подобного использования.

:(

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

у дебиана есть такая особенность -- кое-какие доки попадают в non-free

Package gcc-doc-base lenny (stable) (doc): several GNU manual pages [non-free]

надо добавить non-free в /etc/apt/sources.list

www_linux_org_ru ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Development