Bug#883407: libc6: getpwnam_r() leaks memory

2017-12-09 Thread Felipe Sateler
Control: forwarded -1 https://github.com/systemd/systemd/issues/7596 On Fri, Dec 8, 2017 at 4:15 PM, Aurelien Jarno wrote: > control: reassign -1 systemd > control: retitle -1 libnss-systemd: _nss_systemd_getpwnam_r leaks memory > > Hi, > > On 2017-12-08 16:05, Tim Rühsen wrote: >> On Tue, 5 Dec

Bug#883407: libc6: getpwnam_r() leaks memory

2017-12-08 Thread Aurelien Jarno
control: reassign -1 systemd control: retitle -1 libnss-systemd: _nss_systemd_getpwnam_r leaks memory Hi, On 2017-12-08 16:05, Tim Rühsen wrote: > On Tue, 5 Dec 2017 19:17:42 +0100 Aurelien Jarno > wrote: > > It's not something I can reproduce here, but getpwnam_r can behave very > > differently

Bug#883407: libc6: getpwnam_r() leaks memory

2017-12-08 Thread Tim Rühsen
On Tue, 5 Dec 2017 19:17:42 +0100 Aurelien Jarno wrote: > It's not something I can reproduce here, but getpwnam_r can behave very > differently depending on the nss configuration your system. A small > reproducer and the content of /etc/nsswitch.conf would definitely help. > > That said libc6 ver

Bug#883407: libc6: getpwnam_r() leaks memory

2017-12-05 Thread Tim Ruehsen
Am Dienstag, den 05.12.2017, 19:17 +0100 schrieb Aurelien Jarno: > On 2017-12-03 17:34, Tim Rühsen wrote: > > Package: libc6 > > Version: 2.25-3 > > Severity: normal > > > > Dear Maintainer, > > > > valgrinding a C code shows the following: > > > > ==27943== 4,096 bytes in 1 blocks are definitel

Bug#883407: libc6: getpwnam_r() leaks memory

2017-12-05 Thread Aurelien Jarno
On 2017-12-03 17:34, Tim Rühsen wrote: > Package: libc6 > Version: 2.25-3 > Severity: normal > > Dear Maintainer, > > valgrinding a C code shows the following: > > ==27943== 4,096 bytes in 1 blocks are definitely lost in loss record 3 of 3 > ==27943==by 0x6C27715: getpwnam_r@@GLIBC_2.2.5 (ge

Bug#883407: libc6: getpwnam_r() leaks memory

2017-12-03 Thread Tim Rühsen
Package: libc6 Version: 2.25-3 Severity: normal Dear Maintainer, valgrinding a C code shows the following: ==27943== 4,096 bytes in 1 blocks are definitely lost in loss record 3 of 3 ==27943==by 0x6C27715: getpwnam_r@@GLIBC_2.2.5 (getXXbyYY_r.c:314) ==27943==by 0x4E8569F: rpl_glob (glob.