From: Florian Weimer <fweimer@redhat.com>
To: Charalampos Mitrodimas via Libc-help <libc-help@sourceware.org>
Cc: Charalampos Mitrodimas <charmitro@posteo.net>
Subject: Re: Potential Memory Leak in libc DNS Resolution Functions
Date: Sun, 11 Feb 2024 13:04:25 +0100 [thread overview]
Message-ID: <87zfw7yzp2.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <5a2a1ca4-ebcb-45ea-9b55-ba3f890478b1@posteo.net> (Charalampos Mitrodimas via Libc-help's message of "Sat, 10 Feb 2024 15:22:16 +0000")
* Charalampos Mitrodimas via Libc-help:
> 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)
This is unfortunately not very illuminating because the struct
resolv_conf functions are reference-counted. If there's a counter
management bug somewhere, it would be reported like this by valgrind.
> 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.
I don't recall a problem like this being reported before. Can you
reproduce it on a recent glibc version? We have some cases of
known/intended leaks (if the memory that can be leaked is bounded for
the life-time of the process), but that doesn't apply here. It
certainly looks like something we'd want to fix.
Thanks,
Florian
next prev parent reply other threads:[~2024-02-11 12:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-10 15:22 Charalampos Mitrodimas
2024-02-11 12:04 ` Florian Weimer [this message]
2024-02-12 15:53 ` Charalampos Mitrodimas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zfw7yzp2.fsf@oldenburg.str.redhat.com \
--to=fweimer@redhat.com \
--cc=charmitro@posteo.net \
--cc=libc-help@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).