On 10/11/19 3:33 PM, Alan DeKok wrote:
On Oct 11, 2019, at 9:15 AM, Arnaud LAURIOU<arnaud.lauriou@renater.fr> wrote:
We are suspecting memory leak in FR 3.0.19 : process memory status show VmData always keep increasing leading to VmSwap use after a few days which also keep increasing.
I have 2 questions : - What are the compile options to use valgrind ? only flag --enable-developper ?|| valgrind is a run-time checker, and doesn't need any compile time changes. You just run:
valgrind --tool=memcheck --leak-check=full radiusd -f ...
Note that you will need the "-f".
- In the changelog for version 3.0.20 : some memories problems seems to be solved, do you know when this version will be released ? (if the release date is close, we can wait to test this release rather than 3.0.19) As Matthew says, you can test it now. Thank's for your answers, here are some logs after testing FR 3.0.20 with about a hundred authentications (let me know if you need more specific information from valgrind, I don't know it well) :
==27160== LEAK SUMMARY: ==27160== definitely lost: 9,390 bytes in 50 blocks ==27160== indirectly lost: 308,580 bytes in 2,163 blocks ==27160== possibly lost: 78,682,289 bytes in 13,374 blocks ==27160== still reachable: 1,779,086 bytes in 31,899 blocks ==27160== of which reachable via heuristic: ==27160== length64 : 53,360 bytes in 356 blocks ==27160== newarray : 1,936 bytes in 22 blocks ==27160== suppressed: 0 bytes in 0 blocks ==27160== Reachable blocks (those to which a pointer was found) are not shown. blocks 'definitely lost' : ==27160== 32,936 (136 direct, 32,800 indirect) bytes in 1 blocks are definitely lost in loss record 1,499 of 1,529 ==27160== at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==27160== by 0x840B31E: gnutls_x509_crt_init (in /usr/lib/x86_64-linux-gnu/libgnutls.so.30.14.10) ==27160== by 0x84102A8: gnutls_x509_crt_list_import (in /usr/lib/x86_64-linux-gnu/libgnutls.so.30.14.10) ==27160== by 0x78C5A93: ??? (in /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.8) ==27160== by 0x78C342F: ??? (in /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.8) ==27160== by 0x78B968C: ldap_set_option (in /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.8) ==27160== by 0x7680B53: mod_conn_create (ldap.c:1532) ==27160== by 0x137CDC: fr_connection_spawn (connection.c:438) ==27160== by 0x13859F: fr_connection_get_internal (connection.c:858) ==27160== by 0x767B528: mod_authorize (rlm_ldap.c:1465) ==27160== by 0x131762: call_modsingle (modcall.c:304) ==27160== by 0x131762: modcall_recurse (modcall.c:580) ==27160== by 0x1310A2: modcall_child (modcall.c:410) ==27160== 34,794 (4,320 direct, 30,474 indirect) bytes in 9 blocks are definitely lost in loss record 1,502 of 1,529 ==27160== at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==27160== by 0x83FFF47: gnutls_x509_privkey_init (in /usr/lib/x86_64-linux-gnu/libgnutls.so.30.14.10) ==27160== by 0x78C5A12: ??? (in /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.8) ==27160== by 0x78C342F: ??? (in /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.8) ==27160== by 0x78B968C: ldap_set_option (in /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.8) ==27160== by 0x7680B53: mod_conn_create (ldap.c:1532) ==27160== by 0x137CDC: fr_connection_spawn (connection.c:438) ==27160== by 0x138228: fr_connection_pool_check (connection.c:728) ==27160== by 0x767B677: mod_authorize (rlm_ldap.c:1673) ==27160== by 0x131762: call_modsingle (modcall.c:304) ==27160== by 0x131762: modcall_recurse (modcall.c:580) ==27160== by 0x1310A2: modcall_child (modcall.c:410) ==27160== by 0x13124B: modcall_recurse (modcall.c:791) ==27160== 61,216 (304 direct, 60,912 indirect) bytes in 2 blocks are definitely lost in loss record 1,515 of 1,529 ==27160== at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==27160== by 0x9F4305B: ??? (in /usr/lib/x86_64-linux-gnu/libtasn1.so.6.5.5) ==27160== by 0x9F4326C: asn1_create_element (in /usr/lib/x86_64-linux-gnu/libtasn1.so.6.5.5) ==27160== by 0x840B343: gnutls_x509_crt_init (in /usr/lib/x86_64-linux-gnu/libgnutls.so.30.14.10) ==27160== by 0x84102A8: gnutls_x509_crt_list_import (in /usr/lib/x86_64-linux-gnu/libgnutls.so.30.14.10) ==27160== by 0x78C5A93: ??? (in /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.8) ==27160== by 0x78C342F: ??? (in /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.8) ==27160== by 0x78B968C: ldap_set_option (in /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.8) ==27160== by 0x7680B53: mod_conn_create (ldap.c:1532) ==27160== by 0x137CDC: fr_connection_spawn (connection.c:438) ==27160== by 0x138228: fr_connection_pool_check (connection.c:728) ==27160== by 0x767B677: mod_authorize (rlm_ldap.c:1673) ==27160== 143,384 (1,224 direct, 142,160 indirect) bytes in 9 blocks are definitely lost in loss record 1,520 of 1,529 ==27160== at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==27160== by 0x840B31E: gnutls_x509_crt_init (in /usr/lib/x86_64-linux-gnu/libgnutls.so.30.14.10) ==27160== by 0x84102A8: gnutls_x509_crt_list_import (in /usr/lib/x86_64-linux-gnu/libgnutls.so.30.14.10) ==27160== by 0x78C5A93: ??? (in /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.8) ==27160== by 0x78C342F: ??? (in /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.8) ==27160== by 0x78B968C: ldap_set_option (in /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.8) ==27160== by 0x7680B53: mod_conn_create (ldap.c:1532) ==27160== by 0x137CDC: fr_connection_spawn (connection.c:438) ==27160== by 0x138228: fr_connection_pool_check (connection.c:728) ==27160== by 0x767B677: mod_authorize (rlm_ldap.c:1673) ==27160== by 0x131762: call_modsingle (modcall.c:304) ==27160== by 0x131762: modcall_recurse (modcall.c:580) ==27160== by 0x1310A2: modcall_child (modcall.c:410) Issue with the ldap module ? Regards, Arnaud Lauriou