Bug 116526 - Memory leak in getaddrinfo().
Summary: Memory leak in getaddrinfo().
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc   
(Show other bugs)
Version: 1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-02-22 19:15 UTC by Sam Varshavchik
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-05-12 01:28:25 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2004:143 normal SHIPPED_LIVE GNU C Library bugfix update 2004-05-11 04:00:00 UTC
Red Hat Product Errata RHBA-2004:212 normal SHIPPED_LIVE Updated shadow-utils package available 2004-05-11 04:00:00 UTC
Red Hat Product Errata RHBA-2004:213 normal SHIPPED_LIVE Updated ypserv package available 2004-05-11 04:00:00 UTC

Description Sam Varshavchik 2004-02-22 19:15:10 UTC
Description of problem:

According to valgrind, getaddrinfo() is leaking memory. 
freeaddrinfo() does not release everything that was allocate by

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Compile the following program:  cc -g -o leakcheck leakcheck.c

#include <netdb.h>
int main()
        struct addrinfo hints, *res;
        int i;
        int errcode;
        for (i=0; i<100; i++)
                memset(&hints, 0, sizeof(hints));
                errcode=getaddrinfo("www.cnn.com", "http", &hints, &res);
                if (errcode)
                        printf("%s\n", gai_strerror(errcode));

2. valgrind --num-callers=12 --leak-check=yes ./leakcheck

Actual results:

==12713== Memcheck, a.k.a. Valgrind, a memory error detector for
==12713== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==12713== Using valgrind-2.0.0, a program supervision framework for
==12713== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==12713== Estimated CPU clock rate is 1137 MHz
==12713== For more details, rerun with: -v
==12713== discard syms in /lib/libnss_files-2.3.2.so due to munmap()
==12713== discard syms in /lib/libnss_dns-2.3.2.so due to munmap()
==12713== discard syms in /lib/libresolv-2.3.2.so due to munmap()
==12713== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 1)
==12713== malloc/free: in use at exit: 2772 bytes in 99 blocks.
==12713== malloc/free: 1360 allocs, 1261 frees, 190793 bytes allocated.
==12713== For counts of detected errors, rerun with: -v
==12713== searching for pointers to 99 not-freed blocks.
==12713== checked 4590680 bytes.
==12713== 2772 bytes in 99 blocks are definitely lost in loss record 1
of 1
==12713==    at 0x9ED68E: malloc (vg_replace_malloc.c:153)
==12713==    by 0xD5BE9B: ???
==12713==    by 0xD5AC12: ???
==12713==    by 0xD5B309: ???
==12713==    by 0xD5AF0F: ???
==12713==    by 0x64805D: ???
==12713==    by 0xF86D25: gaih_inet (in /lib/libc-2.3.2.so)
==12713==    by 0xF87923: __GI_getaddrinfo (in /lib/libc-2.3.2.so)
==12713==    by 0x80484D1: main (leakcheck.c:15)
==12713==    by 0xED5BBE: __libc_start_main (in /lib/libc-2.3.2.so)
==12713==    by 0x80483E8: (within /var/tmp/leakcheck)
==12713== LEAK SUMMARY:
==12713==    definitely lost: 2772 bytes in 99 blocks.
==12713==    possibly lost:   0 bytes in 0 blocks.
==12713==    still reachable: 0 bytes in 0 blocks.
==12713==         suppressed: 0 bytes in 0 blocks.
==12713== Reachable blocks (those to which a pointer was found) are
not shown.
==12713== To see them, rerun with: --show-reachable=yes

Comment 1 Jakub Jelinek 2004-02-23 10:53:08 UTC
Ok, fixed in my copy.  Would you like to be listed in the testcase
as its author and if so, is the above email address the one you want to use?

Comment 2 Sam Varshavchik 2004-02-23 12:12:34 UTC
List my address as mrsam@courier-mta.com

Comment 3 John Flanagan 2004-05-12 01:28:26 UTC
An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.


Comment 4 Nigel Horne 2004-11-17 13:30:12 UTC
This problem still occurs in FC3. See also bug 139559.

Comment 5 Jakub Jelinek 2004-11-22 10:44:38 UTC
No, the problem doesn't occur on FC3.  There is completely unrelated problem
newly introduced in FC3, see #139559.

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