Bug 116526 - Memory leak in getaddrinfo().
Memory leak in getaddrinfo().
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-02-22 14:15 EST by Sam Varshavchik
Modified: 2007-11-30 17:10 EST (History)
0 users

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

Attachments (Terms of Use)

  None (edit)
Description Sam Varshavchik 2004-02-22 14:15:10 EST
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 05:53:08 EST
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 07:12:34 EST
List my address as mrsam@courier-mta.com

Comment 3 John Flanagan 2004-05-11 21:28:26 EDT
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 08:30:12 EST
This problem still occurs in FC3. See also bug 139559.
Comment 5 Jakub Jelinek 2004-11-22 05:44:38 EST
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.