FS#52578 - [valgrind] reports Memoryleak with glibc's getaddrinfo

Attached to Project: Arch Linux
Opened by robin (crest) - Monday, 16 January 2017, 16:43 GMT
Last edited by Sven-Hendrik Haase (Svenstaro) - Thursday, 14 October 2021, 21:54 GMT
Task Type Bug Report
Category System
Status Closed
Assigned To Levente Polyak (anthraxx)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Hi,

When i use glibc's getaddrinfo and run valgrind on the compiled binary I get a memory leak reported by valgrind.

I already updated my glibc Version to latest upstream version (2.24.90) and try to reproduce this behaviour on different distros.
When i compile the code on a Fedora VM i dont get any mem leaks reported (also 2.24.90, same Valgrind version, with booth gcc and clang). This is also the reason for issue my request here and not upstream.

I can reproduce this on a different Arch installations.

I am not sure how to debug this further. If somebody has an idea or need additional debugging i would be glad to help.
Hope this is the right place for this "bug" and thanks in advance :)

Additional info:
* Valgrind Version (booth Systems)
valgrind --version
valgrind-3.12.0

* glibc Version (booth Systems)
/lib/libc.so.6
GNU C Library (GNU libc) development release version 2.24.90, by Roland McGrath et al.

* Example c Code:
#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char *argv[])
{
struct addrinfo hints;
struct addrinfo *result;

if (argc < 2) {
fprintf(stderr, "Usage: %s host port...\n", argv[0]);
exit(EXIT_FAILURE);
}

memset(&hints, '\0', sizeof(struct addrinfo));
hints.ai_family = AF_UNSPEC; /* Allow IPv4 or IPv6 */
hints.ai_socktype = SOCK_DGRAM; /* Datagram socket */

getaddrinfo(argv[1], argv[2], &hints, &result);
freeaddrinfo(result);
exit(EXIT_SUCCESS);
}



Steps to reproduce:
compile code: (same with gcc)
#clang -g -o leak leak.c

Run Valgrind:
#valgrind --leak-check=full --trace-children=yes --show-leak-kinds=all ./leak archlinux.org 80

==3440== Memcheck, a memory error detector
==3440== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==3440== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==3440== Command: ./leak archlinux.org 80
==3440==
==3440==
==3440== HEAP SUMMARY:
==3440== in use at exit: 10,390 bytes in 20 blocks
==3440== total heap usage: 158 allocs, 138 frees, 116,037 bytes allocated
==3440==
==3440== 25 bytes in 1 blocks are still reachable in loss record 1 of 12
==3440== at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3440== by 0x401AC29: strdup (strdup.c:42)
==3440== by 0x401628E: _dl_load_cache_lookup (dl-cache.c:305)
==3440== by 0x400872F: _dl_map_object (dl-load.c:2065)
==3440== by 0x40133F8: dl_open_worker (dl-open.c:226)
==3440== by 0x4F55C60: _dl_catch_error (dl-error-skeleton.c:198)
==3440== by 0x4012EE8: _dl_open (dl-open.c:649)
==3440== by 0x6335F85: ???
==3440== by 0x4F55C60: _dl_catch_error (dl-error-skeleton.c:198)
==3440== by 0x63365A8: ???
==3440== by 0x6336011: ???
==3440== by 0x40B9474: ???
==3440==
==3440== 25 bytes in 1 blocks are still reachable in loss record 2 of 12
==3440== at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3440== by 0x400B133: _dl_new_object (dl-object.c:165)
==3440== by 0x40055D4: _dl_map_object_from_fd (dl-load.c:1006)
==3440== by 0x40083F0: _dl_map_object (dl-load.c:2199)
==3440== by 0x40133F8: dl_open_worker (dl-open.c:226)
==3440== by 0x4F55C60: _dl_catch_error (dl-error-skeleton.c:198)
==3440== by 0x4012EE8: _dl_open (dl-open.c:649)
==3440== by 0x6335F85: ???
==3440== by 0x4F55C60: _dl_catch_error (dl-error-skeleton.c:198)
==3440== by 0x63365A8: ???
==3440== by 0x6336011: ???
==3440== by 0x40B9474: ???
==3440==
==3440== 32 bytes in 1 blocks are still reachable in loss record 3 of 12
==3440== at 0x4C2CA40: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3440== by 0x633667E: ???
==3440== by 0x6336011: ???
==3440== by 0x40B9474: ???
==3440== by 0x40BBECF: ???
==3440== by 0x4F0A4F0: gaih_inet.constprop.5 (getaddrinfo.c:830)
==3440== by 0x4F0B7F7: getaddrinfo (getaddrinfo.c:2373)
==3440== by 0x4006F6: main (leak.c:20)
==3440==
==3440== 56 bytes in 1 blocks are still reachable in loss record 4 of 12
==3440== at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3440== by 0x40119DC: allocate_dtv_entry (dl-tls.c:591)
==3440== by 0x40119DC: allocate_and_init (dl-tls.c:616)
==3440== by 0x40119DC: tls_get_addr_tail (dl-tls.c:796)
==3440== by 0x40BC4DF: ???
==3440== by 0x40BA68B: ???
==3440== by 0x40DECF0: ???
==3440== by 0x40BBB8C: ???
==3440== by 0x4F0A4F0: gaih_inet.constprop.5 (getaddrinfo.c:830)
==3440== by 0x4F0B7F7: getaddrinfo (getaddrinfo.c:2373)
==3440== by 0x4006F6: main (leak.c:20)
==3440==
==3440== 64 bytes in 1 blocks are still reachable in loss record 5 of 12
==3440== at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3440== by 0x4014763: _dl_close_worker (dl-close.c:393)
==3440== by 0x4014DCD: _dl_close (dl-close.c:840)
==3440== by 0x4F55C60: _dl_catch_error (dl-error-skeleton.c:198)
==3440== by 0x4F553A6: dlerror_run (dl-libc.c:46)
==3440== by 0x4F80436: free_mem (in /usr/lib/libc-2.24.90.so)
==3440== by 0x4F80132: __libc_freeres (in /usr/lib/libc-2.24.90.so)
==3440== by 0x4A2573F: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-amd64-linux.so)
==3440== by 0x4E6CA22: __run_exit_handlers (exit.c:98)
==3440== by 0x4E6CAC9: exit (exit.c:105)
==3440== by 0x400709: main (leak.c:22)
==3440==
==3440== 69 bytes in 3 blocks are still reachable in loss record 6 of 12
==3440== at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3440== by 0x401AC29: strdup (strdup.c:42)
==3440== by 0x401628E: _dl_load_cache_lookup (dl-cache.c:305)
==3440== by 0x400872F: _dl_map_object (dl-load.c:2065)
==3440== by 0x400CD7F: openaux (dl-deps.c:63)
==3440== by 0x4F55C60: _dl_catch_error (dl-error-skeleton.c:198)
==3440== by 0x400CFEE: _dl_map_object_deps (dl-deps.c:254)
==3440== by 0x4013466: dl_open_worker (dl-open.c:269)
==3440== by 0x4F55C60: _dl_catch_error (dl-error-skeleton.c:198)
==3440== by 0x4012EE8: _dl_open (dl-open.c:649)
==3440== by 0x4F5531C: do_dlopen (dl-libc.c:87)
==3440== by 0x4F55C60: _dl_catch_error (dl-error-skeleton.c:198)
==3440==
==3440== 69 bytes in 3 blocks are still reachable in loss record 7 of 12
==3440== at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3440== by 0x400B133: _dl_new_object (dl-object.c:165)
==3440== by 0x40055D4: _dl_map_object_from_fd (dl-load.c:1006)
==3440== by 0x40083F0: _dl_map_object (dl-load.c:2199)
==3440== by 0x400CD7F: openaux (dl-deps.c:63)
==3440== by 0x4F55C60: _dl_catch_error (dl-error-skeleton.c:198)
==3440== by 0x400CFEE: _dl_map_object_deps (dl-deps.c:254)
==3440== by 0x4013466: dl_open_worker (dl-open.c:269)
==3440== by 0x4F55C60: _dl_catch_error (dl-error-skeleton.c:198)
==3440== by 0x4012EE8: _dl_open (dl-open.c:649)
==3440== by 0x4F5531C: do_dlopen (dl-libc.c:87)
==3440== by 0x4F55C60: _dl_catch_error (dl-error-skeleton.c:198)
==3440==
==3440== 216 bytes in 1 blocks are still reachable in loss record 8 of 12
==3440== at 0x4C2CA40: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3440== by 0x40109AD: _dl_check_map_versions (dl-version.c:293)
==3440== by 0x4013966: dl_open_worker (dl-open.c:275)
==3440== by 0x4F55C60: _dl_catch_error (dl-error-skeleton.c:198)
==3440== by 0x4012EE8: _dl_open (dl-open.c:649)
==3440== by 0x6335F85: ???
==3440== by 0x4F55C60: _dl_catch_error (dl-error-skeleton.c:198)
==3440== by 0x63365A8: ???
==3440== by 0x6336011: ???
==3440== by 0x40B9474: ???
==3440== by 0x40BBECF: ???
==3440== by 0x4F0A4F0: gaih_inet.constprop.5 (getaddrinfo.c:830)
==3440==
==3440== 1,008 bytes in 3 blocks are still reachable in loss record 9 of 12
==3440== at 0x4C2CA40: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3440== by 0x40109AD: _dl_check_map_versions (dl-version.c:293)
==3440== by 0x4013966: dl_open_worker (dl-open.c:275)
==3440== by 0x4F55C60: _dl_catch_error (dl-error-skeleton.c:198)
==3440== by 0x4012EE8: _dl_open (dl-open.c:649)
==3440== by 0x4F5531C: do_dlopen (dl-libc.c:87)
==3440== by 0x4F55C60: _dl_catch_error (dl-error-skeleton.c:198)
==3440== by 0x4F553A6: dlerror_run (dl-libc.c:46)
==3440== by 0x4F55421: __libc_dlopen_mode (dl-libc.c:163)
==3440== by 0x4F3E5EF: nss_load_library (nsswitch.c:358)
==3440== by 0x4F3EDD7: __nss_lookup_function (nsswitch.c:455)
==3440== by 0x4F0A497: gaih_inet.constprop.5 (getaddrinfo.c:821)
==3440==
==3440== 1,184 bytes in 1 blocks are still reachable in loss record 10 of 12
==3440== at 0x4C2CA40: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3440== by 0x400AE75: _dl_new_object (dl-object.c:75)
==3440== by 0x40055D4: _dl_map_object_from_fd (dl-load.c:1006)
==3440== by 0x40083F0: _dl_map_object (dl-load.c:2199)
==3440== by 0x40133F8: dl_open_worker (dl-open.c:226)
==3440== by 0x4F55C60: _dl_catch_error (dl-error-skeleton.c:198)
==3440== by 0x4012EE8: _dl_open (dl-open.c:649)
==3440== by 0x6335F85: ???
==3440== by 0x4F55C60: _dl_catch_error (dl-error-skeleton.c:198)
==3440== by 0x63365A8: ???
==3440== by 0x6336011: ???
==3440== by 0x40B9474: ???
==3440==
==3440== 3,546 bytes in 3 blocks are still reachable in loss record 11 of 12
==3440== at 0x4C2CA40: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3440== by 0x400AE75: _dl_new_object (dl-object.c:75)
==3440== by 0x40055D4: _dl_map_object_from_fd (dl-load.c:1006)
==3440== by 0x40083F0: _dl_map_object (dl-load.c:2199)
==3440== by 0x400CD7F: openaux (dl-deps.c:63)
==3440== by 0x4F55C60: _dl_catch_error (dl-error-skeleton.c:198)
==3440== by 0x400CFEE: _dl_map_object_deps (dl-deps.c:254)
==3440== by 0x4013466: dl_open_worker (dl-open.c:269)
==3440== by 0x4F55C60: _dl_catch_error (dl-error-skeleton.c:198)
==3440== by 0x4012EE8: _dl_open (dl-open.c:649)
==3440== by 0x4F5531C: do_dlopen (dl-libc.c:87)
==3440== by 0x4F55C60: _dl_catch_error (dl-error-skeleton.c:198)
==3440==
==3440== 4,096 bytes in 1 blocks are definitely lost in loss record 12 of 12
==3440== at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3440== by 0x40BC741: ???
==3440== by 0x40BA68B: ???
==3440== by 0x40DECF0: ???
==3440== by 0x40BBB8C: ???
==3440== by 0x4F0A4F0: gaih_inet.constprop.5 (getaddrinfo.c:830)
==3440== by 0x4F0B7F7: getaddrinfo (getaddrinfo.c:2373)
==3440== by 0x4006F6: main (leak.c:20)
==3440==
==3440== LEAK SUMMARY:
==3440== definitely lost: 4,096 bytes in 1 blocks
==3440== indirectly lost: 0 bytes in 0 blocks
==3440== possibly lost: 0 bytes in 0 blocks
==3440== still reachable: 6,294 bytes in 19 blocks
==3440== suppressed: 0 bytes in 0 blocks
==3440==
==3440== For counts of detected and suppressed errors, rerun with: -v
==3440== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)


Output on Fedora machine:
==1409== Memcheck, a memory error detector
==1409== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==1409== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==1409== Command: ./leak archlinux.org 80
==1409==
==1409==
==1409== HEAP SUMMARY:
==1409== in use at exit: 0 bytes in 0 blocks
==1409== total heap usage: 86 allocs, 86 frees, 92,408 bytes allocated
==1409==
==1409== All heap blocks were freed -- no leaks are possible
==1409==
==1409== For counts of detected and suppressed errors, rerun with: -v
==1409== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)


#ldd:
ldd leak
linux-vdso.so.1 (0x00007fffe82c6000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f316f268000)
/lib64/ld-linux-x86-64.so.2 (0x00007f316f606000)
ll /usr/lib/libc.so.6
lrwxrwxrwx 1 root root 15 25. Dez 01:37 /usr/lib/libc.so.6 -> libc-2.24.90.so

#Fedora:
ldd leak
linux-vdso.so.1 (0x00007ffd9f9b6000)
libc.so.6 => /lib64/libc.so.6 (0x00007f14524ae000)
/lib64/ld-linux-x86-64.so.2 (0x00007f145284c000)
ll /lib64/libc.so.6
lrwxrwxrwx. 1 root root 15 25. Dez 21:35 /lib64/libc.so.6 -> libc-2.24.90.so


#uname -a
Linux archclient 4.9.4-1-ARCH #1 SMP PREEMPT Mon Jan 16 06:40:51 CET 2017 x86_64 GNU/Linux
Linux fedoraclient 4.9.3-200.fc25.x86_64 #1 SMP Fri Jan 13 01:01:13 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
   leak.c (0.5 KiB)
This task depends upon

Closed by  Sven-Hendrik Haase (Svenstaro)
Thursday, 14 October 2021, 21:54 GMT
Reason for closing:  Fixed
Additional comments about closing:  2021-07-18: A task closure has been requested. Reason for request: "All heap blocks were freed -- no leaks are possible" Not confirmed in the latest version with patches. https://bugs.archlinux.org/task/71543
Comment by Allan McRae (Allan) - Tuesday, 17 January 2017, 09:46 GMT
My guess is valgrind needs a suppression added.
Comment by robin (crest) - Tuesday, 17 January 2017, 10:43 GMT
Good point. Never think about the default suppression files deployed, so i make a diff between the default.supp from arch linux valgrind-3.12.0-1-x86_64.pkg.tar.xz and fedoras valgrind-3.12.0-1.fc25.x86_64.rpm.

Maybe this is useful:
>diff arch/usr/lib/valgrind/default.supp fedora/usr/lib64/valgrind/default.supp
991a992,997
> helgrind-glibc2X-102a
> Helgrind:Race
> fun:mythread_wrapper
> obj:*vgpreload_helgrind*.so
> }
> {
1305c1311
< obj:*ld-2.24.*.so
---
> obj:*ld-2.24*.so
1317c1323
< obj:*ld-2.24.*.so
---
> obj:*ld-2.24*.so
1324c1330
< obj:*lib*2.24.*.so
---
> obj:*lib*2.24*.so

Loading...