утечка памяти getpwnam_r

Я использую getpwnam_r для обработки клиентских подключений в своих программах. К сожалению, кажется, что он выделяет буфер, который никогда не освобождается. Соответствующий вывод valgrind:


==15774== 536 (104 direct, 432 indirect) bytes in 2 blocks are definitely lost in loss record 1 of 3
==15774==    at 0x4C24CFE: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==15774==    by 0x5143B5A: nss_parse_service_list (in /lib64/libc-2.10.1.so)
==15774==    by 0x51442E6: __nss_database_lookup (in /lib64/libc-2.10.1.so)
==15774==    by 0x57BE35F: ???
==15774==    by 0x57BF3F6: ???
==15774==    by 0x51014D2: getpwnam_r@@GLIBC_2.2.5 (in /lib64/libc-2.10.1.so)
==15774==    by 0x407906: dopass (auth.c:71)
==15774==    by 0x40393E: do_cmd (command.c:127)
==15774==    by 0x402496: ftp_main (server.c:58)
==15774==    by 0x40224C: handle_client (daemon.c:211)
==15774==    by 0x402073: daemon_main (daemon.c:123)
==15774==    by 0x4043CC: main (main.c:48)
==15774== 
==15774== LEAK SUMMARY:
==15774==    definitely lost: 104 bytes in 2 blocks.
==15774==    indirectly lost: 432 bytes in 18 blocks.
==15774==      possibly lost: 0 bytes in 0 blocks.
==15774==    still reachable: 0 bytes in 0 blocks.
==15774==         suppressed: 0 bytes in 0 blocks.

Есть ли способ сказать getpwnam_r, чтобы освободить буферы? Или мне придется подавлять эти ошибки Valgrind?

Спасибо, Каспер


c memory-leaks glibc valgrind
person Kasper    schedule 18.09.2009    source источник
comment
Я думаю, что это дубликат, см. здесь: stackoverflow.com/questions/188591/   -  person schnaader    schedule 19.09.2009
comment
@schnaader: Внимательнее посмотрите на вопросы. Это не дубликат, потому что getpwnam страдает от той же самой утечки памяти, что и эта функция. Вопрос только что касался статических данных, выделенных getpwnam, а не getpwnam_r.   -  person Kasper    schedule 19.09.2009

Ответы (1)


arrow_upward
7
arrow_downward

Память на самом деле не выделяется специально для getpwnam. Вместо этого он представляет конфигурацию /etc/nsswitch.conf. AFAICT, единственный способ освободить libc эту память - вызвать __libc_freeres:

extern void __libc_freeres (void);

Предполагается, что это освободит всю память, которую удерживает библиотека C (а не только память, которую удерживает NSS).

person Martin v. Löwis    schedule 18.09.2009