Я разрабатываю статически связанное 64-битное приложение C ++ на 64-битной CentOS 5.8, используя стандартные пакеты gcc 4.4 из репозиториев CentOS. Кажется, он использует больше памяти, чем я ожидал, поэтому я попытался использовать массив для профилирования использования памяти. Я скомпилировал с отладочной информацией и затем запустил
valgrind —tool = массив. / MyProg
из каталога, где находится MyProg. Он никогда не дает никаких результатов, кроме следующего примера massif.out.XXXX.
desc: (none)
cmd: ./MyProg
time_unit: i
#-----------
snapshot=0
#-----------
time=0
mem_heap_B=0
mem_heap_extra_B=0
mem_stacks_B=0
heap_tree=empty
Обратите внимание, что это все содержимое файла, и моя программа может работать в течение многих минут.
Я пробовал разные варианты валгринда и массива безрезультатно. Я даже попытался использовать абсолютный путь к MyProg, на всякий случай. Я попытался загрузить самую последнюю стабильную версию valgrind (3.8.1) и скомпилировать и запустить ее (поскольку CentOS использует 3.5.0) с тем же результатом. В качестве проверки работоспособности я побежал
valgrind —tool = массив ls -l
и это произвело многократные снимки с ненулевым использованием памяти, как ожидалось.
Я пытался искать в Интернете, используя каждую комбинацию ключевых слов, о которых только мог подумать, но не нашел подобных проблем.
В качестве примечания, я могу успешно профилировать приложение, используя инструмент memcheck по умолчанию от valgrind, если это полезная информация.
Кто-нибудь знает, почему массив не сможет профилировать мое приложение?
Если приложение статически связано, его нельзя проанализировать с помощью valgrind. Valgrind работает, предоставляя свою версию функций распределения вашей программе, что достигается путем переопределения динамического поиска.
Если вы можете динамически связываться со стандартными библиотеками (libc и libstdc ++), то он, вероятно, сможет выполнить анализ памяти, который вы ищете.
Во-вторых, если ваша программа статически связана, большинство инструментов Valgrind также не будут работать, потому что они не смогут заменить некоторые функции, такие как malloc, своими собственными версиями.
Других решений пока нет …