From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) by sourceware.org (Postfix) with ESMTPS id DFEAE3858C54 for ; Sat, 10 Feb 2024 15:22:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DFEAE3858C54 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=posteo.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=posteo.net ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DFEAE3858C54 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=185.67.36.66 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707578554; cv=none; b=AVxeLDKW3zwiftl+C9eNdGStSt9y/OG6MtoO5VCYyrE7TH8FHo0XA1iFpfCe3+E3i+TIg1XLK/qkR+1z5zPgrxsDS2S/nF9nxmkCDJ0hBeciyuEAVDJbNH7pkmy3mTYOhA4gTmNJ9i4DSmRiO26kjYZL1tFgDfLJA7KmraDtj3Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707578554; c=relaxed/simple; bh=hTFv/BdFImOmwQ/im4sG+3CDM5nNh2m/7afd71LWEMc=; h=DKIM-Signature:Message-ID:Date:MIME-Version:From:To:Subject; b=nDwyRZQSSgw9qUJL0sq1pIvVqgWPK4GeBUCSIIPBBAhWDq0TrUvtZyragu1WhFCFoiKcBPNpoOx1wsnUgUPQT+zdseKxHnJuf4/xLb7znXdlnH8NlltDyq2D1P1rbV3bXJbiboYz5kOXXLIaFmZxWN/szXtIdhtFMv1Lu7gbeOw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 5A88F240101 for ; Sat, 10 Feb 2024 16:22:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1707578549; bh=hTFv/BdFImOmwQ/im4sG+3CDM5nNh2m/7afd71LWEMc=; h=Message-ID:Date:MIME-Version:From:To:Subject:Content-Type: Content-Transfer-Encoding:From; b=a6PZN4SjubUp4ucWd00qOjhLwaWNVBvvY/o3XSg5BrqJA9iNOLWbRosbpNNv1NUki 798r9hupmONCOd5+7+/aWaylnM63lazoF/BivNhmwwuSq28RHHr9YHTDy1FGQACYvl 9GMuK/Vkeus6Iwu8T9YtBNz6qObaGmwInLVSrkU/zN2P7rEN5ZL5RfIKqx5JOnyfJZ S+cOhjUa1JSdKI5ljXSd5Duz0xeH4HpZCk0sLXg9SZJRK9AE+3Gsi6S82aJpCrpHat NPIwytBZ7BwHNIEGQ4HCvMlolPou8NfQed0aT81FkSjdsMVO0axZYSUTGTns5oixVV T8bpcsa5tXmPg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4TXDx03Zy8z6tw8 for ; Sat, 10 Feb 2024 16:22:28 +0100 (CET) Message-ID: <5a2a1ca4-ebcb-45ea-9b55-ba3f890478b1@posteo.net> Date: Sat, 10 Feb 2024 15:22:16 +0000 MIME-Version: 1.0 From: Charalampos Mitrodimas Content-Language: en-US To: libc-help@sourceware.org Subject: Potential Memory Leak in libc DNS Resolution Functions Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello, I've encountered a potential memory leak in libc, specifically within the DNS resolution functions, as identified by Valgrind. The leak involves __libc_alloc_buffer_allocate and related functions. Here's the Valgrind output snippet:    ==4151== 156 bytes in 1 blocks are definitely lost in loss record 730 of 1,029    ==4151==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)    ==4151==    by 0x4D15048: __libc_alloc_buffer_allocate (alloc_buffer_allocate.c:26)    ==4151==    by 0x4DBDC65: alloc_buffer_allocate (alloc_buffer.h:143)    ==4151==    by 0x4DBDC65: __resolv_conf_allocate (resolv_conf.c:391)    ==4151==    by 0x4DB8D0A: __resolv_conf_load (res_init.c:599)    ==4151==    by 0x4DBD85E: __resolv_conf_get_current (resolv_conf.c:140)    ==4151==    by 0x4DB9394: __res_vinit (res_init.c:628)    ==4151==    by 0x4DBE82F: maybe_init (resolv_context.c:122)    ==4151==    by 0x4DBE82F: context_get (resolv_context.c:184)    ==4151==    by 0x4DBE82F: context_get (resolv_context.c:176)    ==4151==    by 0x4DBE82F: __resolv_context_get (resolv_context.c:195)    ==4151==    by 0x4D78C87: get_nss_addresses (getaddrinfo.c:617)    ==4151==    by 0x4D78C87: gaih_inet (getaddrinfo.c:1179)    ==4151==    by 0x4D78C87: getaddrinfo (getaddrinfo.c:2397)    ==4151==    by 0x4A7108E: >::try_from::{{closure}} (net.rs:207)    ==4151==    by 0x4A6A105: <(&str,u16) as std::net::socket_addr::ToSocketAddrs>::to_socket_addrs (small_c_string.rs:43)    ==4151==    by 0x495356A: lettre::transport::smtp::client::net::NetworkStream::connect::try_connect (net.rs:104)    ==4151==    by 0x49532F1: lettre::transport::smtp::client::net::NetworkStream::connect (net.rs:139) This issue arose in an application using Rust's email library Lettre, ultimately traced back to libc during DNS resolution. Could you please advise if this is a known issue and recommend any steps to address it? I'm willing to contribute a fix, but want to make sure this is of concern for the libc team, before starting the investigation. Thank you for your support.           Charalampos Mitrodimas