* Potential Memory Leak in libc DNS Resolution Functions
@ 2024-02-10 15:22 Charalampos Mitrodimas
2024-02-11 12:04 ` Florian Weimer
0 siblings, 1 reply; 3+ messages in thread
From: Charalampos Mitrodimas @ 2024-02-10 15:22 UTC (permalink / raw)
To: libc-help
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: <std::sys_common::net::LookupHost as
core::convert::TryFrom<(&str,u16)>>::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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Potential Memory Leak in libc DNS Resolution Functions
2024-02-10 15:22 Potential Memory Leak in libc DNS Resolution Functions Charalampos Mitrodimas
@ 2024-02-11 12:04 ` Florian Weimer
2024-02-12 15:53 ` Charalampos Mitrodimas
0 siblings, 1 reply; 3+ messages in thread
From: Florian Weimer @ 2024-02-11 12:04 UTC (permalink / raw)
To: Charalampos Mitrodimas via Libc-help; +Cc: Charalampos Mitrodimas
* 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Potential Memory Leak in libc DNS Resolution Functions
2024-02-11 12:04 ` Florian Weimer
@ 2024-02-12 15:53 ` Charalampos Mitrodimas
0 siblings, 0 replies; 3+ messages in thread
From: Charalampos Mitrodimas @ 2024-02-12 15:53 UTC (permalink / raw)
To: Charalampos Mitrodimas via Libc-help; +Cc: Florian Weimer
Hi Florian,
On 2/11/24 14:04, Florian Weimer wrote:
> * 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 for replying!
Yes, I'll try to provide more information, debug different
versions and reach back.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-02-12 15:53 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-10 15:22 Potential Memory Leak in libc DNS Resolution Functions Charalampos Mitrodimas
2024-02-11 12:04 ` Florian Weimer
2024-02-12 15:53 ` Charalampos Mitrodimas
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).