Bug 139559 - Memory leak in curl_easy_perform
Summary: Memory leak in curl_easy_perform
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc   
(Show other bugs)
Version: 3
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-11-16 17:54 UTC by Nigel Horne
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

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: ---


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

Description Nigel Horne 2004-11-16 17:54:19 UTC
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 17:55:20 UTC
Created attachment 106826 [details]
Reproduce libcurl memory leak

Compile and run the attached source file.

Comment 2 Nigel Horne 2004-11-17 13:31:19 UTC
See also bug 116526.

Comment 3 Daniel Stenberg 2004-11-17 13:51:08 UTC
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 13:57:12 UTC
So where should the bug be logged? 

Comment 5 Nigel Horne 2004-11-22 08:40:04 UTC
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 08:49:28 UTC
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 10:34:37 UTC
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 12:46:04 UTC
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.