Solaris LIBUMEM: получить "libmapmalloc.so.1 not found", когда приложение C выполняет SUBPROCESS?
У меня есть приложение 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 export UMEM_DEBUG= аудит
Также, пожалуйста, исправьте меня, если я ошибаюсь, но если подпроцесс завершается, то любая "утечка памяти" в этом подпроцессе будет автоматически освобождена, верно? Таким образом, я могу предположить, что никакие утечки на Солярисе не поступают от вызова подпроцесса?
Любая помощь в этом отношении будет принята с благодарностью
Спасибо за помощь
Линтон
1 ответ
Такое поведение уже наблюдалось, когда код, использующий dlerror, ошибочно предполагает, что он возвращает ненулевое значение, в то время как dlopen успешен (см. Эту почту: обсуждение в indiana.) Я бы начал с отслеживания вашего приложения, чтобы увидеть, вызваны ли эти функции и как.
/usr/lib/libmapmalloc.so.1 действительно 32-битный, но если ваше приложение 64-битное, оно использует что-то вроде /usr/lib/amd64/libmapmalloc.so или аналогичное.
Вы правы, утверждая, что когда (под) процесс завершается, все его выделение памяти освобождается.