From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.3)
Description of problem:
Running the attached program generates a memory leak even though it
clears up by calling curl_slist_free_all and curl_easy_cleanup.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. cc -g `curl-config --libs` f.c
2. valgrind --tool=memcheck --num-callers=25 --leak-check=yes ./a.out
==11191== 12 bytes in 1 blocks are definitely lost in loss record 1 of 1
==11191== at 0x1B904A90: malloc (vg_replace_malloc.c:131)
==11191== by 0x1BBDCAEF: strdup (in /lib/tls/libc-2.3.3.so)
==11191== by 0x1BC21CDD: gaih_inet (in /lib/tls/libc-2.3.3.so)
==11191== by 0x1BC236D0: getaddrinfo (in /lib/tls/libc-2.3.3.so)
==11191== by 0x1B94CF23: Curl_getaddrinfo (in
==11191== by 0x1B92C7C9: Curl_resolv (in /usr/lib/libcurl.so.3.0.0)
==11191== by 0x1B93C1BD: Curl_connect (in /usr/lib/libcurl.so.3.0.0)
==11191== by 0x1B94734C: (within /usr/lib/libcurl.so.3.0.0)
==11191== by 0x1B947573: Curl_perform (in /usr/lib/libcurl.so.3.0.0)
==11191== by 0x1B947CC1: curl_easy_perform (in
==11191== by 0x80489D3: main (f.c:101)
Expected Results: There should be no memory leak.
Created attachment 106826 [details]
Reproduce libcurl memory leak
Compile and run the attached source file.
See also bug 116526.
Exactly, this is not a curl bug at all.
So where should the bug be logged?
Why have you marked this as "not a bug" without giving a reason when
clearly there *is* a memory leak???
Comment 5: because this is "not a bug" with curl, which is what it's
While I could just change the component to glibc, a more generalized
reproduction case and/or a re-opening of bug 116526 with an updated
release would be more helpful imo.
freeaddrinfo() is properly paired with getaddrinfo(), as the libcurl
mailing list mentions, in addition to the acknowledged leak wrt glibc
in bug 116526.
Yes, this is a glibc bug, but completely unrelated to #116526.
for a fix.
Should be fixed in glibc-2.3.3-84.