Bug 139559
| Summary: | Memory leak in curl_easy_perform | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Nigel Horne <njh> | ||||
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | Brian Brock <bbrock> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 3 | CC: | havill | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | 2.3.3-84 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2004-11-24 12:46:04 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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. |
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: