由於getaddrinfo（），Valgrind內存泄漏

Question

我將TCP流套接字連接到給定的主機名和端口。 要獲取主機的IP地址，請按以下方式使用getaddrinfo（）

struct addrinfo hints;
struct addrinfo *result, *server;

memset(&hints, 0, sizeof(struct addrinfo)); // fill server with 0

hints.ai_family = AF_INET;   // set address family
hints.ai_protocol=0;    // set protocol type to auto
hints.ai_socktype = SOCK_STREAM;    // set type of socket to stream socket

if(getaddrinfo(HOSTNAME,PORT,&hints,&result)){
    perror("Could not resolve IP from given hostname and port (getaddrinfo)");
    freeaddrinfo(result);
    return -1;
}

if(print) printf("Connecting socket ... \n");
int connectFlag=1;
for(server=result;server!=NULL;server=server->ai_next){
    if(connect(sockfd,server->ai_addr,server->ai_addrlen)==-1){
        continue;
    }
    if(print){
        printf("Socket successfully connected\n");
    }
    break;
}

if(!connectFlag){
    printf("Could not connect to server %s.\n",HOSTNAME);
    close(sockfd);
    freeaddrinfo(result);
    return -1;
}

freeaddrinfo(result);

所有這一切都發生在一個傳遞參數的函數中

int sockfd = socket(AF_INET,SOCK_STREAM,0);

從另一個功能。 一切正常，套接字連接，我按預期接收和發送消息。

問題是，當我檢查創建的二進制文件時

valgrind --leak-check=full --trace-children=yes ./binary

我得到3313個字節仍然可以訪問 。 當手動解析主機並直接使用IP連接時，不會出現泄漏。 我用較舊的gethostbyname（）替換了getaddrinfo（），並得到了相同數量的仍可訪問的字節。

我如何擺脫這些泄漏？

Valgrind輸出

   % valgrind --leak-check=full --show-leak-kinds=all ./play
==16353== Memcheck, a memory error detector
==16353== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==16353== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==16353== Command: ./a.out
==16353== 
==16353== 
==16353== HEAP SUMMARY:
==16353==     in use at exit: 3,313 bytes in 10 blocks
==16353==   total heap usage: 96 allocs, 86 frees, 54,234 bytes allocated
==16353== 
==16353== 64 bytes in 2 blocks are still reachable in loss record 1 of 5
==16353==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16353==    by 0x4016790: _dl_close_worker.part.0 (dl-close.c:393)
==16353==    by 0x4017029: _dl_close_worker (dl-close.c:125)
==16353==    by 0x4017029: _dl_close (dl-close.c:822)
==16353==    by 0x4010393: _dl_catch_error (dl-error.c:187)
==16353==    by 0x4F7CBAE: dlerror_run (dl-libc.c:46)
==16353==    by 0x4F7CBAE: __libc_dlclose (dl-libc.c:222)
==16353==    by 0x4FADB66: free_mem (in /lib/x86_64-linux-gnu/libc-2.23.so)
==16353==    by 0x4FAD78F: __libc_freeres (in /lib/x86_64-linux-gnu/libc-2.23.so)
==16353==    by 0x4A2868C: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-amd64-linux.so)
==16353==    by 0x4E73FAA: __run_exit_handlers (exit.c:97)
==16353==    by 0x4E74044: exit (exit.c:104)
==16353==    by 0x404162: cleanUp (in /home/a)
==16353==    by 0x401CB7: dispatch (in /home/a)
==16353== 
==16353== 71 bytes in 2 blocks are still reachable in loss record 2 of 5
==16353==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16353==    by 0x401CD89: strdup (strdup.c:42)
==16353==    by 0x401860E: _dl_load_cache_lookup (dl-cache.c:311)
==16353==    by 0x4008F98: _dl_map_object (dl-load.c:2342)
==16353==    by 0x400D9D1: openaux (dl-deps.c:63)
==16353==    by 0x4010393: _dl_catch_error (dl-error.c:187)
==16353==    by 0x400E011: _dl_map_object_deps (dl-deps.c:254)
==16353==    by 0x4015411: dl_open_worker (dl-open.c:280)
==16353==    by 0x4010393: _dl_catch_error (dl-error.c:187)
==16353==    by 0x4014BD8: _dl_open (dl-open.c:660)
==16353==    by 0x4F7C9BC: do_dlopen (dl-libc.c:87)
==16353==    by 0x4010393: _dl_catch_error (dl-error.c:187)
==16353== 
==16353== 71 bytes in 2 blocks are still reachable in loss record 3 of 5
==16353==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16353==    by 0x400BD23: _dl_new_object (dl-object.c:165)
==16353==    by 0x400633C: _dl_map_object_from_fd (dl-load.c:1006)
==16353==    by 0x4008A56: _dl_map_object (dl-load.c:2476)
==16353==    by 0x400D9D1: openaux (dl-deps.c:63)
==16353==    by 0x4010393: _dl_catch_error (dl-error.c:187)
==16353==    by 0x400E011: _dl_map_object_deps (dl-deps.c:254)
==16353==    by 0x4015411: dl_open_worker (dl-open.c:280)
==16353==    by 0x4010393: _dl_catch_error (dl-error.c:187)
==16353==    by 0x4014BD8: _dl_open (dl-open.c:660)
==16353==    by 0x4F7C9BC: do_dlopen (dl-libc.c:87)
==16353==    by 0x4010393: _dl_catch_error (dl-error.c:187)
==16353== 
==16353== 744 bytes in 2 blocks are still reachable in loss record 4 of 5
==16353==    at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16353==    by 0x4011EED: _dl_check_map_versions (dl-version.c:293)
==16353==    by 0x4015948: dl_open_worker (dl-open.c:286)
==16353==    by 0x4010393: _dl_catch_error (dl-error.c:187)
==16353==    by 0x4014BD8: _dl_open (dl-open.c:660)
==16353==    by 0x4F7C9BC: do_dlopen (dl-libc.c:87)
==16353==    by 0x4010393: _dl_catch_error (dl-error.c:187)
==16353==    by 0x4F7CA73: dlerror_run (dl-libc.c:46)
==16353==    by 0x4F7CA73: __libc_dlopen_mode (dl-libc.c:163)
==16353==    by 0x4F623BD: nss_load_library (nsswitch.c:358)
==16353==    by 0x4F630F3: __nss_lookup_function (nsswitch.c:466)
==16353==    by 0x4F630F3: __nss_next2 (nsswitch.c:242)
==16353==    by 0x4F535FA: gethostbyname2_r@@GLIBC_2.2.5 (getXXbyYY_r.c:281)
==16353==    by 0x4F259DE: gaih_inet (getaddrinfo.c:622)
==16353== 
==16353== 2,363 bytes in 2 blocks are still reachable in loss record 5 of 5
==16353==    at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16353==    by 0x400BA25: _dl_new_object (dl-object.c:75)
==16353==    by 0x400633C: _dl_map_object_from_fd (dl-load.c:1006)
==16353==    by 0x4008A56: _dl_map_object (dl-load.c:2476)
==16353==    by 0x400D9D1: openaux (dl-deps.c:63)
==16353==    by 0x4010393: _dl_catch_error (dl-error.c:187)
==16353==    by 0x400E011: _dl_map_object_deps (dl-deps.c:254)
==16353==    by 0x4015411: dl_open_worker (dl-open.c:280)
==16353==    by 0x4010393: _dl_catch_error (dl-error.c:187)
==16353==    by 0x4014BD8: _dl_open (dl-open.c:660)
==16353==    by 0x4F7C9BC: do_dlopen (dl-libc.c:87)
==16353==    by 0x4010393: _dl_catch_error (dl-error.c:187)
==16353== 
==16353== LEAK SUMMARY:
==16353==    definitely lost: 0 bytes in 0 blocks
==16353==    indirectly lost: 0 bytes in 0 blocks
==16353==      possibly lost: 0 bytes in 0 blocks
==16353==    still reachable: 3,313 bytes in 10 blocks
==16353==         suppressed: 0 bytes in 0 blocks
==16353== 
==16353== For counts of detected and suppressed errors, rerun with: -v
==16353== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

如果添加valgrind選項--trace-children = yes valgrind將檢查子進程。 我沒有輸出此消息，因為此父進程中發生了泄漏 。

編輯

原來，我們無法在其他硬件上重現valgrind輸出。 在此服務器上，getaddrinfo（）生成了此valgrind輸出以及gethostbyname（）。 我們沒有進一步觀察到這種行為可能來自何處。

Answer 1

“仍可訪問”表示程序已分配內存，並且在終止時仍對其具有引用。 這可能意味着第一個調用中的getaddrinfo（）和gethostbyname（）分配了可重用的內存。

該SO-answer可能也適用： https : //stackoverflow.com/a/13230399/2696475