Solaris LIBUMEM: получить «libmapmalloc.so.1 not found», когда приложение C выполняет SUBPROCESS? - PullRequest
0 голосов
/ 27 ноября 2011

У меня есть приложение C, которое работает в Linux, Solaris и AIX. Я использовал такие инструменты, как TotalView MemoryScape, чтобы отследить утечки памяти в Linux, и он на 100% чист. Тем не менее, я заметил небольшую утечку на Solaris.

Так что я использовал "libumem" в Solaris, чтобы попытаться найти утечки.

Мое приложение либо вызывает «выход пользователя» (через вызов подпроцесса), либо нет.

Так что, если я запускаю приложение без пользовательских выходов (следовательно, нет вызова подпроцесса), то libumem работает на 100% .... и я не вижу утечек до сих пор ...

LD_PRELOAD = libumem.so UMEM_DEBUG = аудит ./myapplication config.ini

Но когда я включаю вызов пользователя для выхода из системы, чтобы основное приложение вызывало подпроцессы, я получаю в STDOUT следующую подпрограмму во время выполнения:

ld.so.1: userexit_proxy: fatal: libmapmalloc.so.1: Нет такого файла или каталога

ОБРАТИТЕ ВНИМАНИЕ, что если я не использую "libumem", тогда приложение будет работать на 100% ... (все еще небольшая утечка памяти)

Теперь мое приложение скомпилировано в 64-битной версии, и я заметил, что /usr/lib/libmapmalloc.so.1 является 32-битной, но это не должно иметь никакого значения ....

Есть идеи, как использовать libumem в приложении, которое также вызывает подпроцессы?

ПРИМЕЧАНИЕ. Я также пытался экспортировать переменные во всю среду, но все равно не повезло

export LD_PRELOAD = libumem.so экспорт UMEM_DEBUG = аудит

Также, пожалуйста, исправьте меня, если я ошибаюсь, но если подпроцесс завершается, тогда любая «утечка памяти» в этом подпроцессе будет автоматически освобождена, верно? Таким образом, я могу предположить, что никакие утечки на Солярисе не поступают от вызова подпроцесса?

Любая помощь в этом отношении будет принята с благодарностью

Спасибо за помощь

Линтон

1 Ответ

0 голосов
/ 27 ноября 2011

Такое поведение уже наблюдалось, когда код, использующий dlerror, ошибочно предполагает, что он возвращает ненулевое значение, в то время как dlopen успешен (см. Эту почту: indiana обсудите .). Я бы начал с отслеживания вашего приложения, чтобы увидеть, еслиэти функции и как.

/ usr / lib / libmapmalloc.so.1 действительно 32-битные, но если ваше приложение 64-битное, оно использует что-то вроде /usr/lib/amd64/libmapmalloc.so или аналогичное.

Вы правы, утверждая, что когда (под) процесс завершается, все его выделение памяти освобождается.

...