Bug 139559 - Memory leak in curl_easy_perform
Memory leak in curl_easy_perform
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-16 12:54 EST by Nigel Horne
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.3.3-84
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-24 07:46:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Reproduce libcurl memory leak (2.79 KB, text/plain)
2004-11-16 12:55 EST, Nigel Horne
no flags Details

  None (edit)
Description Nigel Horne 2004-11-16 12:54:19 EST
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:
Comment 1 Nigel Horne 2004-11-16 12:55:20 EST
Created attachment 106826 [details]
Reproduce libcurl memory leak

Compile and run the attached source file.
Comment 2 Nigel Horne 2004-11-17 08:31:19 EST
See also bug 116526.
Comment 3 Daniel Stenberg 2004-11-17 08:51:08 EST
Exactly, this is not a curl bug at all.

http://curl.haxx.se/mail/lib-2004-11/0191.html
Comment 4 Nigel Horne 2004-11-17 08:57:12 EST
So where should the bug be logged? 
Comment 5 Nigel Horne 2004-11-22 03:40:04 EST
Why have you marked this as "not a bug" without giving a reason when 
clearly there *is* a memory leak??? 
Comment 6 Eido Inoue 2004-11-22 03:49:28 EST
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.

Comment 7 Jakub Jelinek 2004-11-22 05:34:37 EST
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.
Comment 8 Jakub Jelinek 2004-11-24 07:46:04 EST
Should be fixed in glibc-2.3.3-84.

Note You need to log in before you can comment on or make changes to this bug.