Hide Forgot
Description of problem: Somewhere between krb5-libs-1.6.1-31.el5_3.3 and krb5-libs-1.6.1-62.el5 a memory leak may have been introduced. Version-Release number of selected component (if applicable): krb5-libs-1.6.1-62.el5 How reproducible: Always Steps to Reproduce: 1. valgrind --leak-check=full --show-reachable=yes /usr/sbin/saslauthd -m /var/run/saslauthd -a kerberos5 -n1 -d 2. Run testsaslauthd 3. valgrind will report multiple records like this one: ==30002== 11,537 (551 direct, 10,986 indirect) bytes in 1 blocks are definitely lost in loss record 91 of 91 ==30002== at 0x4A0610C: malloc (vg_replace_malloc.c:195) ==30002== by 0x30964011E3: ??? ==30002== by 0x34DF411F30: ??? ==30002== by 0x34DF048071: ??? ==30002== by 0x34DF0488A7: ??? ==30002== by 0x34DF0196E0: ??? ==30002== by 0x34DF019FE7: ??? ==30002== by 0x5037DCF: ??? ==30002== by 0x503952D: ??? ==30002== by 0x309DC6137E: krb5_do_preauth (in /usr/lib64/libkrb5.so.3.3) ==30002== by 0x309DC57E77: krb5_get_init_creds (in /usr/lib64/libkrb5.so.3.3) ==30002== by 0x309DC59BD3: krb5_get_init_creds_password (in /usr/lib64/libkrb5.so.3.3) 4. Run valgrind --leak-check=full --show-reachable=yes `which kinit` 5. ==29967== 11,537 (551 direct, 10,986 indirect) bytes in 1 blocks are definitely lost in loss record 79 of 79 ==29967== at 0x4A0610C: malloc (vg_replace_malloc.c:195) ==29967== by 0x78C11E3: ??? ==29967== by 0x76B3F30: ??? ==29967== by 0x73BB071: ??? ==29967== by 0x73BB8A7: ??? ==29967== by 0x738C6E0: ??? ==29967== by 0x738CFE7: ??? ==29967== by 0x6CF7DCF: ??? ==29967== by 0x6CF952D: ??? ==29967== by 0x509B37E: krb5_do_preauth (in /usr/lib64/libkrb5.so.3.3) ==29967== by 0x5091E77: krb5_get_init_creds (in /usr/lib64/libkrb5.so.3.3) ==29967== by 0x5093BD3: krb5_get_init_creds_password (in /usr/lib64/libkrb5.so.3.3) Actual results: For a program like kinit, this is not a big deal. For a daemon like saslauthd, saslauthd's memory usage will grow for as long as the process is running. (See bugzilla report #757844) Expected results: Programs using krb5-libs should not leak. Additional info:
Do you have pkinit-nss installed? I'm suspecting that loading the plugin, along with NSS on which it depends, is causing the memory to be allocated and then not freed when the plugin is subsequently unloaded.
Yes, the servers have pkinit-nss installed. I uninstalled pkinit-nss from the test machine and it looks like the leak is gone.
Okay, since the pkinit implementation is a different one in EL6, I'm going to mark this as resolved in the next release.