winbind 3.3.7 memory usage

[Volker Lendecke]

On Mon, Oct 05, 2009 at 09:03:58AM +0200, Dr. Hansjoerg Maurer wrote:
> If run winbind with valgrind for 4 days no
> One winbind (PID 14762) grows up to 727/448 MByte VSZ/RSS
>  
> [root at donau ~]# psgrep winbind
> root     11749  0.1  5.7 394492 119072 ?     Ss   Oct01  10:09 valgrind --tool=memcheck --leak-check=full -v --num-callers=20 --trace-children=yes winbindd
> root     11806  0.0  3.0 351088 62516 ?      S    Oct01   0:05 valgrind --tool=memcheck --leak-check=full -v --num-callers=20 --trace-children=yes winbindd
> root     11807  0.0  3.2 357580 67176 ?      S    Oct01   0:06 valgrind --tool=memcheck --leak-check=full -v --num-callers=20 --trace-children=yes winbindd
> root     12053  0.0  3.3 355820 68288 ?      S    Oct01   0:14 valgrind --tool=memcheck --leak-check=full -v --num-callers=20 --trace-children=yes winbindd
> root     12054  0.0  4.5 370644 92540 ?      S    Oct01   0:39 valgrind --tool=memcheck --leak-check=full -v --num-callers=20 --trace-children=yes winbindd
> root     14502  0.2  5.0 393100 104816 ?     S    Oct01  15:04 valgrind --tool=memcheck --leak-check=full -v --num-callers=20 --trace-children=yes winbindd
> root     14762  6.6 21.8 727332 448924 ?     R    Oct01 371:14 valgrind --tool=memcheck --leak-check=full -v --num-callers=20 --trace-children=yes winbindd
> 
> 
> The valgrind output has a uncompressed size of 440 MByte's (compressed 4 MByte) 

Ok, that one seems like a valgrind artifact. It seems not to
complain about something in the Kerberos libraries, which
are, as we all know, perfect. (sorry...).

The only significant memory leak as reported by valgrind is
in the idmap child:

==14502== 83,415 bytes in 4,020 blocks are definitely lost in loss record 61 of 67
==14502==    at 0x4904A06: malloc (vg_replace_malloc.c:149)
==14502==    by 0x3B8E570FF1: strdup (in /lib64/tls/libc-2.3.4.so)
==14502==    by 0x14A71A61: ???
==14502==    by 0x14A7EBA4: ???
==14502==    by 0x14A85CAC: ???
==14502==    by 0x14A864F0: ???
==14502==    by 0x14A81CAD: ???
==14502==    by 0x147C51A7: ???
==14502==    by 0x147C7294: ???
==14502==    by 0x3B8E58E75E: getgrnam_r@@GLIBC_2.2.5 (in /lib64/tls/libc-2.3.4.so)
==14502==    by 0x3B8E58DDBE: getgrnam (in /lib64/tls/libc-2.3.4.so)
==14502==    by 0x391938: ??? (idmap_nss.c:189)
==14502==    by 0x387E72: idmap_backends_sid_to_unixid (idmap.c:785)
==14502==    by 0x388F0C: idmap_sid_to_gid (idmap_util.c:259)
==14502==    by 0xBFBE7: winbindd_dual_sid2gid (winbindd_idmap.c:374)
==14502==    by 0xB71B8: ??? (winbindd_dual.c:453)
==14502==    by 0xB7971: ??? (winbindd_dual.c:214)
==14502==    by 0xB7E2E: ??? (winbindd_dual.c:189)
==14502==    by 0x1445CB: run_events (events.c:233)
==14502==    by 0x85961: main (winbindd.c:850)

It seems that on your system getgrnam internally leaks
memory. There's nothing Samba can do about this.

Hope that helps,

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20091005/e66e2015/attachment.pgp>