From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2C3E43858C39; Sun, 23 Jan 2022 19:59:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2C3E43858C39 From: "alex at eadem dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/28808] New: leak on fedora 33 and higher in getaddrinfo Date: Sun, 23 Jan 2022 19:59:47 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.33 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: alex at eadem dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2022 19:59:48 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28808 Bug ID: 28808 Summary: leak on fedora 33 and higher in getaddrinfo Product: glibc Version: 2.33 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libc Assignee: unassigned at sourceware dot org Reporter: alex at eadem dot com CC: drepper.fsp at gmail dot com Target Milestone: --- potential leak confirmed by the valgrind team https://bugs.kde.org/show_bug.cgi?id=3D448991 Starting with=20 Fedora 33 glibc-2.32-10.fc33.x86_64 NAME=3DFedora VERSION=3D"33 (Container Image)" Valgrind on Fedora 32 doesn't report the memory leak valgrind reports (See complete stack trace below ) ... =3D=3D18=3D=3D by 0x401DE9F: strdup (strdup.c:42) =3D=3D18=3D=3D by 0x40184F4: _dl_load_cache_lookup (dl-cache.c:312) ... on program exit It looks to be related to: getaddrinfo STEPS TO REPRODUCE ``` #include #include #include #include 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 =3D AF_UNSPEC; /* Allow IPv4 or IPv6 */ hints.ai_socktype =3D SOCK_DGRAM; /* Datagram socket */ getaddrinfo(argv[1], argv[2], &hints, &result); freeaddrinfo(result); exit(EXIT_SUCCESS); ``` compile with: ``` clang -g -o leak leak.c valgrind --leak-check=3Dfull --trace-children=3Dyes --show-leak-kinds=3Dall= ./leak archlinux.org 80 ``` OBSERVED RESULT leak EXPECTED RESULT no leaks as in fedora 32 SOFTWARE/OS VERSIONS Windows:=20 macOS:=20 Linux/KDE Plasma:=20 (available in About System) KDE Plasma Version:=20 KDE Frameworks Version:=20 Qt Version:=20 ADDITIONAL INFORMATION =3D=3D18=3D=3D Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyrigh= t info =3D=3D18=3D=3D Command: /usr/bin/api --debug =3D=3D18=3D=3D=20 =3D=3D18=3D=3D=20 =3D=3D18=3D=3D HEAP SUMMARY: =3D=3D18=3D=3D in use at exit: 5,061 bytes in 12 blocks =3D=3D18=3D=3D total heap usage: 121,783 allocs, 121,771 frees, 171,928,5= 44 bytes allocated =3D=3D18=3D=3D=20 =3D=3D18=3D=3D 21 bytes in 1 blocks are still reachable in loss record 1 of= 7 =3D=3D18=3D=3D at 0x4839809: malloc (vg_replace_malloc.c:307) =3D=3D18=3D=3D by 0x401DE9F: malloc (rtld-malloc.h:56) =3D=3D18=3D=3D by 0x401DE9F: strdup (strdup.c:42) =3D=3D18=3D=3D by 0x40184F4: _dl_load_cache_lookup (dl-cache.c:312) =3D=3D18=3D=3D by 0x400A046: _dl_map_object (dl-load.c:2185) =3D=3D18=3D=3D by 0x400E694: openaux (dl-deps.c:64) =3D=3D18=3D=3D by 0x5139BB7: _dl_catch_exception (in /usr/lib64/libc-2.3= 2.so) =3D=3D18=3D=3D by 0x400EADA: _dl_map_object_deps (dl-deps.c:248) =3D=3D18=3D=3D by 0x4014B09: dl_open_worker (dl-open.c:584) =3D=3D18=3D=3D by 0x5139BB7: _dl_catch_exception (in /usr/lib64/libc-2.3= 2.so) =3D=3D18=3D=3D by 0x401460D: _dl_open (dl-open.c:864) =3D=3D18=3D=3D by 0x5138FE0: do_dlopen (in /usr/lib64/libc-2.32.so) =3D=3D18=3D=3D by 0x5139BB7: _dl_catch_exception (in /usr/lib64/libc-2.3= 2.so) =3D=3D18=3D=3D=20 =3D=3D18=3D=3D 21 bytes in 1 blocks are still reachable in loss record 2 of= 7 =3D=3D18=3D=3D at 0x4839809: malloc (vg_replace_malloc.c:307) =3D=3D18=3D=3D by 0x400C8B8: UnknownInlinedFun (rtld-malloc.h:56) =3D=3D18=3D=3D by 0x400C8B8: _dl_new_object (dl-object.c:196) =3D=3D18=3D=3D by 0x400841A: _dl_map_object_from_fd (dl-load.c:1073) =3D=3D18=3D=3D by 0x4009B3A: _dl_map_object (dl-load.c:2319) =3D=3D18=3D=3D by 0x400E694: openaux (dl-deps.c:64) =3D=3D18=3D=3D by 0x5139BB7: _dl_catch_exception (in /usr/lib64/libc-2.3= 2.so) =3D=3D18=3D=3D by 0x400EADA: _dl_map_object_deps (dl-deps.c:248) =3D=3D18=3D=3D by 0x4014B09: dl_open_worker (dl-open.c:584) =3D=3D18=3D=3D by 0x5139BB7: _dl_catch_exception (in /usr/lib64/libc-2.3= 2.so) =3D=3D18=3D=3D by 0x401460D: _dl_open (dl-open.c:864) =3D=3D18=3D=3D by 0x5138FE0: do_dlopen (in /usr/lib64/libc-2.32.so) =3D=3D18=3D=3D by 0x5139BB7: _dl_catch_exception (in /usr/lib64/libc-2.3= 2.so --=20 You are receiving this mail because: You are on the CC list for the bug.=