From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.3) Gecko/20041020 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): curl-7.12.1-1 How reproducible: Always Steps to Reproduce: 1. cc -g `curl-config --libs` f.c 2. valgrind --tool=memcheck --num-callers=25 --leak-check=yes ./a.out 3. Actual Results: ==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 /usr/lib/libcurl.so.3.0.0) ==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 /usr/lib/libcurl.so.3.0.0) ==11191== by 0x80489D3: main (f.c:101) Expected Results: There should be no memory leak. Additional info:
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. http://curl.haxx.se/mail/lib-2004-11/0191.html
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 filed under. 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. See http://sources.redhat.com/ml/libc-hacker/2004-11/msg00056.html for a fix.
Should be fixed in glibc-2.3.3-84.