После распределения памяти в gdb

Question

Почему сканирование памяти непредсказуемо, когда я просматриваю программу в отладчике gdb? Я пытаюсь использовать gdb, чтобы узнать, почему программа использует гораздо больше памяти, чем должна, и она не сотрудничает.

Я шагаю через исходный код во время мониторинга использования памяти процесса, но я не могу найти какую строку() распределяет память по двум причинам:

1. Сообщил использование памяти только вскакивает с шагом (обычно, но не всегда точно) 64 МБ. Я подозреваю, что вижу эффекты какого-либо менеджера памяти. Я не знаю, какие резервы 64 МБ за один раз и маскирует несколько меньших распределений.
2. Скачок не происходит в согласованном месте в коде. Это происходит не только на разных линиях во время различных прогонов gdb; это также иногда происходит в нелогичных местах, таких как закрывающая скобка (C++). Возможно ли, что сам gdb влияет на распределение памяти?

Любые идеи/предложения для более эффективных инструментов, которые помогут мне перейти к строкам кода, которые действительно ответственны за эти распределения памяти?

Вот некоторые сведения о системе: Я запускаю x86_64-redhat-linux-gnu версию 7.2-64.el6-5.2 на виртуальной машине CentOS Linux под Windows. Программа построена на удаленном сервере с помощью сложного сценария сборки, поэтому отслеживание того, какие опции использовались в любой момент, само по себе является немного сложной задачей. Я отслеживаю использование памяти как с помощью утилиты top («virt» или столбец виртуальной памяти), так и путем чтения файла мониторинга в реальном времени /proc/<pid>/status, и они согласны. Поскольку в этой программе используется большой набор сторонних библиотек, может быть задействована одна или несколько переопределенных функций malloc(), о которых я не знаю - их поиск - часть этой задачи.

Answer 1

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

Однако это также зависит от способа использования gdb. Если вы просто устанавливаете простые точки останова, шагаете и печатаете вещи, тогда вы в порядке. Но иногда, чтобы оценить выражение, gdb будет выделять память в нижнем. Например, если у вас есть условие точки останова, например strcmp(arg, "string") == 0, тогда gdb будет выделять память для этой строковой константы. Есть и другие подобные ситуации.

Answer 2

Этот ответ в несколько частей, потому что было несколько вещей происходит:

1. Valgrind с модулем Массива (профайлер памяти) было гораздо более полезным, чем gdb для этой проблемы. Иногда быстрый просмотр с отладчиком работает, иногда это не так. http://valgrind.org/docs/manual/ms-manual.html
2. top - плохой инструмент для профилирования использования памяти, поскольку он сообщает только о распределении виртуальной памяти, который в этом случае составляет около 3x фактического использования памяти кучи. Виртуальная память сопоставляется и становится доступной ядром Unix, когда процесс запрашивает блок памяти, но он не обязательно используется. Основной системный вызов - mmap(). Я до сих пор не знаю, как проверить размер блока. top может рассказать вам, что ядро ​​Unix знает о потреблении памяти, чего недостаточно, чтобы быть полезным. Не используйте его (или файлы памяти в/proc /) для детального профилирования памяти.
3. Распределение памяти при выходе из функции было вызвано автозагрузками - это класс блокировки потоков, деструктор которого блокирует блокировку при выходе из области видимости.Затем другой поток переходит в действие и выделяет некоторую память, оставляя оператора (меня) мистифицированным. Непрерывность, вероятно, связана с тем, что некоторые потоки ожидали внешних ресурсов, таких как интернет-соединения.