Есть ли исправление или решение проблемы утечки памяти в getpwnam?

Question

Есть ли исправление или способ устранения утечки памяти в getpwnam?

Answer 1

getpwnam() не страдает от утечки памяти. Последующие вызовы действительно перезапишут его статический внутренний буфер.

Такого рода функции вместо этого не входящие и, следовательно, не поточно-безопасные . Пол предложил использовать getpwnam_r(), который является повторно входящей версией, которая безопасна для использования в многопоточном контексте.

При этом утечки памяти вызваны теми системными вызовами, которые выделяют память с помощью malloc() и оставляют приложение ответственным за free() память после использования возвращаемых данных.

В этих случаях рекомендуется использовать идиому RAII, чтобы не забыть освободить выделенную память - см. Исключение безопасности. std::tr1::shared_ptr<> также является жизнеспособным способом: для shared_ptr пользовательский указатель должен быть предоставлен free() необработанному указателю, когда shared_ptr выходит из области видимости.

С этой точки зрения некоторые опасные функции: scandir(), asprintf(), vasprintf() и т. Д.

Answer 2

Используйте getpwnam_r.

Answer 3

Я не думаю, что есть обходной путь. Ответы выше не помогают, см .:

daniel@senap:~/dev/tryouts$ uname -a
Linux senap 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
daniel@senap:~/dev/tryouts$ cat getpwnam-leak.c 
#include <sys/types.h>
#include <pwd.h>

extern void __libc_freeres(void);

int main()
{
  char buf[1024];
  struct passwd pw, *result;
  getpwnam_r("root", &pw, buf, sizeof(buf), &result);
  __libc_freeres();
}
daniel@senap:~/dev/tryouts$ valgrind --leak-check=full ./getpwnam-leak
==6951== Memcheck, a memory error detector
==6951== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==6951== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==6951== Command: ./getpwnam-leak
==6951== 
==6951== 
==6951== HEAP SUMMARY:
==6951==     in use at exit: 300 bytes in 11 blocks
==6951==   total heap usage: 69 allocs, 58 frees, 9,234 bytes allocated
==6951== 
==6951== 300 (60 direct, 240 indirect) bytes in 1 blocks are definitely lost in loss record 11 of 11
==6951==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==6951==    by 0x4F35D94: nss_parse_service_list (nsswitch.c:678)
==6951==    by 0x4F36855: __nss_database_lookup (nsswitch.c:175)
==6951==    by 0x55F32A4: ???
==6951==    by 0x4EEF1AC: getpwnam_r@@GLIBC_2.2.5 (getXXbyYY_r.c:256)
==6951==    by 0x400607: main (in /home/daniel/dev/tryouts/getpwnam-leak)
==6951== 
==6951== LEAK SUMMARY:
==6951==    definitely lost: 60 bytes in 1 blocks
==6951==    indirectly lost: 240 bytes in 10 blocks
==6951==      possibly lost: 0 bytes in 0 blocks
==6951==    still reachable: 0 bytes in 0 blocks
==6951==         suppressed: 0 bytes in 0 blocks
==6951== 
==6951== For counts of detected and suppressed errors, rerun with: -v
==6951== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
daniel@senap:~/dev/tryouts$ 

Answer 4

Чтобы это исправить, просто сделайте:

sudo sed -i s/compat/files/g /etc/nsswitch.conf

Похоже, это вызвано ошибкой в ​​libnss_compat. Больше информации на bugs.debian.org .