2009-09-18 3 views
4

내 프로그램에서 클라이언트 연결을 처리하기 위해 getpwnam_r을 사용합니다. 슬프게도, 결코 풀어주지 않는 버퍼를 할당하는 것 같습니다. 관련 Valgrind의 출력 :getpwnam_r memory leak


==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: [email protected]@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 오류를 억제해야합니까?

감사합니다. Kasper

+0

나는 이것이 중복 된 것이라고 생각합니다. http://stackoverflow.com/questions/188591/is-there-a-fix-or-a-workaround-for-the-memory-leak-in-getpwnam/266785 – schnaader

+0

@schnaader : 질문을 자세히 살펴보십시오. getpwnam은이 함수와 똑같은 메모리 누수로 고통 받기 때문에 중복이 아닙니다. getpwnam_r이 할당하지 않은 정적 데이터 getpwnam에 대한 질문이 방금 참조했습니다. – kmm

답변

7

메모리가 실제로 getpwnam에 실제로 할당되지 않았습니다. 대신 /etc/nsswitch.conf의 구성을 나타냅니다. C 라이브러리는 (NSS가 점유뿐 아니라 메모리)에 보유하고 있음이 모든 메모리를 해제하도록되어

extern void __libc_freeres (void); 

: AFAICT는 유일한 방법은 __libc_freeres를 호출을 통해이 메모리는 libc의 버전이 있습니다.