Geek Answers Handbook

Is there a fix or workaround for memory leak in getpwnam?

Is there a fix or workaround for memory leak in getpwnam?

+1
source share
4 answers

getpwnam() does not suffer a memory leak . Subsequent calls will indeed overwrite its static internal buffer.

Such functions are instead not reentrant and therefore unsafe. Paul suggested using getpwnam_r() , which is a reentrant version that is safe to use in a multi-threaded context.

However, a memory leak is caused by those system calls that allocate memory using malloc() and leave the application responsible for free() memory after using the returned data.

In these cases, the RAII idiom is recommended so as not to forget to free the allocated memory - see exception safety. std::tr1::shared_ptr<> also a viable way: for shared_ptr, the user removed must be given free() raw pointer when shared_ptr goes out of scope.

In this perspective, some dangerous functions are scandir() , asprintf() , vasprintf() , etc.

+7
source

Use getpwnam_r.

+3
source

I do not think there is a workaround. The answers above do not help, see:

 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$
+2
source

To fix this, do the following:

 sudo sed -is/compat/files/g /etc/nsswitch.conf

This seems to be caused by an error in libnss_compat. Additional information at bugs.debian.org .

0
source

More articles:


All Articles