4

I use getpwnam_r to handle client connections in my programs. Sadly enough, it seems to allocate a buffer it never frees. The relevant valgrind output:


==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.

Ise there a way to tell getpwnam_r to release it's buffers? Or will I have to suppress these Valgrind errors?

Thanks, Kasper

Kasper
  • 2,451
  • 2
  • 17
  • 19
  • I think this is a duplicate, see here: http://stackoverflow.com/questions/188591/is-there-a-fix-or-a-workaround-for-the-memory-leak-in-getpwnam/266785 – schnaader Sep 18 '09 at 22:20
  • @schnaader: Take a better look at the questions. It's not a duplicate because getpwnam suffer from the exact same memory leak as this function. The question just referred to the static data getpwnam allocated that getpwnam_r does not. – Kasper Sep 18 '09 at 22:28

1 Answers1

7

The memory isn't really allocated for getpwnam specifically. Instead, it represents the configuration of /etc/nsswitch.conf. AFAICT, the only way to have libc release this memory is through calling __libc_freeres:

extern void __libc_freeres (void);

This is supposed to release all memory that the C library holds onto (not just the memory NSS holds onto).

Martin v. Löwis
  • 124,830
  • 17
  • 198
  • 235