`
#include <curl/curl.h>
int main(int argc, char *argv[]){
curl_global_init(CURL_GLOBAL_DEFAULT);
CURL *curl = curl_easy_init();
if(curl) {
curl_easy_setopt(curl, CURLOPT_URL, "https://example.com");
curl_easy_perform(curl);
curl_easy_cleanup(curl);
}
curl_global_cleanup();
}
` Consider the simplest example of LibcURL, running on fedora 35, with libcurl-devel-7.79.1-7.fc35.x86_64.
Running:
`valgrind --tool=memcheck --track-origins=yes --leak-check=full --show-leak-kinds=all --track-fds=yes -s
` Gives:
==435227== LEAK SUMMARY:
==435227== definitely lost: 0 bytes in 0 blocks
==435227== indirectly lost: 0 bytes in 0 blocks
==435227== possibly lost: 0 bytes in 0 blocks
==435227== still reachable: 3,453 bytes in 8 blocks
==435227== suppressed: 0 bytes in 0 blocks
==435227==
==435227== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
I understood this is not an error, still there are 8 blocks not free:
==435227== FILE DESCRIPTORS: 3 open (3 std) at exit.
==435227==
==435227== HEAP SUMMARY:
==435227== in use at exit: 3,453 bytes in 8 blocks
==435227== total heap usage: 33,900 allocs, 33,892 frees, 3,454,387 bytes allocated
People have suggested using another distribution of curl: https://github.com/clearlinux-pkgs/curl
Another suggestion is to suppress the warnings in Valgrind.
Is there is a know solution for this?
==435227== 57 bytes in 2 blocks are still reachable in loss record 1 of 4
==435227== at 0x48447AB: malloc (vg_replace_malloc.c:381)
==435227== by 0x402745F: malloc (rtld-malloc.h:56)
==435227== by 0x402745F: strdup (strdup.c:42)
==435227== by 0x4018997: _dl_load_cache_lookup (dl-cache.c:517)
==435227== by 0x400DA77: _dl_map_object (dl-load.c:2152)
==435227== by 0x401142B: dl_open_worker_begin (dl-open.c:533)
==435227== by 0x4E57D77: _dl_catch_exception (dl-error-skeleton.c:208)
==435227== by 0x4010BE9: dl_open_worker (dl-open.c:777)
==435227== by 0x4E57D77: _dl_catch_exception (dl-error-skeleton.c:208)
==435227== by 0x4010FDE: _dl_open (dl-open.c:878)
==435227== by 0x4E58170: do_dlopen (dl-libc.c:96)
==435227== by 0x4E57D77: _dl_catch_exception (dl-error-skeleton.c:208)
==435227== by 0x4E57E42: _dl_catch_error (dl-error-skeleton.c:227)
==435227==
==435227== 57 bytes in 2 blocks are still reachable in loss record 2 of 4
==435227== at 0x48447AB: malloc (vg_replace_malloc.c:381)
==435227== by 0x4010978: UnknownInlinedFun (rtld-malloc.h:56)
==435227== by 0x4010978: _dl_new_object (dl-object.c:199)
==435227== by 0x400C1D0: _dl_map_object_from_fd (dl-load.c:1058)
==435227== by 0x400D95E: _dl_map_object (dl-load.c:2286)
==435227== by 0x401142B: dl_open_worker_begin (dl-open.c:533)
==435227== by 0x4E57D77: _dl_catch_exception (dl-error-skeleton.c:208)
==435227== by 0x4010BE9: dl_open_worker (dl-open.c:777)
==435227== by 0x4E57D77: _dl_catch_exception (dl-error-skeleton.c:208)
==435227== by 0x4010FDE: _dl_open (dl-open.c:878)
==435227== by 0x4E58170: do_dlopen (dl-libc.c:96)
==435227== by 0x4E57D77: _dl_catch_exception (dl-error-skeleton.c:208)
==435227== by 0x4E57E42: _dl_catch_error (dl-error-skeleton.c:227)
==435227==
==435227== 912 bytes in 2 blocks are still reachable in loss record 3 of 4
==435227== at 0x4849218: calloc (vg_replace_malloc.c:1328)
==435227== by 0x4017DBC: UnknownInlinedFun (rtld-malloc.h:44)
==435227== by 0x4017DBC: _dl_check_map_versions (dl-version.c:274)
==435227== by 0x40114D2: dl_open_worker_begin (dl-open.c:599)
==435227== by 0x4E57D77: _dl_catch_exception (dl-error-skeleton.c:208)
==435227== by 0x4010BE9: dl_open_worker (dl-open.c:777)
==435227== by 0x4E57D77: _dl_catch_exception (dl-error-skeleton.c:208)
==435227== by 0x4010FDE: _dl_open (dl-open.c:878)
==435227== by 0x4E58170: do_dlopen (dl-libc.c:96)
==435227== by 0x4E57D77: _dl_catch_exception (dl-error-skeleton.c:208)
==435227== by 0x4E57E42: _dl_catch_error (dl-error-skeleton.c:227)
==435227== by 0x4E580CF: dlerror_run (dl-libc.c:46)
==435227== by 0x4E582B6: __libc_dlopen_mode (dl-libc.c:163)
==435227==
==435227== 2,427 bytes in 2 blocks are still reachable in loss record 4 of 4
==435227== at 0x4849218: calloc (vg_replace_malloc.c:1328)
==435227== by 0x4010682: UnknownInlinedFun (rtld-malloc.h:44)
==435227== by 0x4010682: _dl_new_object (dl-object.c:92)
==435227== by 0x400C1D0: _dl_map_object_from_fd (dl-load.c:1058)
==435227== by 0x400D95E: _dl_map_object (dl-load.c:2286)
==435227== by 0x401142B: dl_open_worker_begin (dl-open.c:533)
==435227== by 0x4E57D77: _dl_catch_exception (dl-error-skeleton.c:208)
==435227== by 0x4010BE9: dl_open_worker (dl-open.c:777)
==435227== by 0x4E57D77: _dl_catch_exception (dl-error-skeleton.c:208)
==435227== by 0x4010FDE: _dl_open (dl-open.c:878)
==435227== by 0x4E58170: do_dlopen (dl-libc.c:96)
==435227== by 0x4E57D77: _dl_catch_exception (dl-error-skeleton.c:208)
==435227== by 0x4E57E42: _dl_catch_error (dl-error-skeleton.c:227)
I've try isolating the problem and debugging with Valgrind
