Посмертный поиск утечки памяти (и анализ) с помощью gdb

Моя общая цель состоит в том, чтобы выяснить из файла ядра post mortem, почему конкретный процесс потребляет много памяти. Могу ли я как-нибудь получить резюме? Очевидно, что о valgrind не может быть и речи, потому что я не могу получить доступ к процессу вживую.

Прежде всего, получение вывода, похожего на / proc / "pid" / maps, могло бы помочь, но

maintenance info sections

(как описано здесь: GDB: перечисление всех отображенных областей памяти для аварийного процесса ) в gdb не показывал мне потребление памяти кучи.

info proc map

- это вариант, так как я могу получить доступ к машине с точно таким же кодом, но, насколько я видел, это неверно. В моем процессе использовалось 700 МБ, но отображаемые карты занимали только около 10 МБ. И я не видел там .so-s, которые видны в

maintenance print statistics

. Знаете ли вы какие-нибудь другие команды, которые могут быть полезны?

Я всегда могу инструментировать код, но это непросто. Достижение всех выделенных данных с помощью указателей похоже на иголку в стоге сена.

У вас есть идеи?

6
задан Community 23 May 2017 в 12:31
поделиться