free radius 2.2.6 it works well on production system and one day we change to not write accouting data to database directly, instead, we write it to detail disk file and sync to db latter. after this change we found the memory consumption increase day by day. with valgrind I test it in lab environment with same configuration. here is the output: anybody can help if this is leak and if newest 3.2.x already fixed it? valgrind --leak-check=full --time-stamp=yes --show-leak-kinds=all --log-file=/tmp/valgrind.log /usr/sbin/freeradius ==00:00:00:07.586 59730== LEAK SUMMARY: ==00:00:00:07.586 59730== definitely lost: 125 bytes in 3 blocks ==00:00:00:07.586 59730== indirectly lost: 480 bytes in 20 blocks ==00:00:00:07.586 59730== possibly lost: 0 bytes in 0 blocks ==00:00:00:07.586 59730== still reachable: 6,173,476 bytes in 70,774 blocks ==00:00:00:07.586 59730== suppressed: 0 bytes in 0 blocks ==00:00:00:07.586 59730== ==00:00:00:07.586 59730== For counts of detected and suppressed errors, rerun with: -v ==00:00:00:07.586 59730== Use --track-origins=yes to see where uninitialised values come from ==00:00:00:07.586 59730== ERROR SUMMARY: 41122 errors from 100 contexts (suppressed: 0 from 0) ==00:00:03:34.727 59824== Thread 6: ==00:00:00:07.569 59730== 160 bytes in 4 blocks are still reachable in loss record 891 of 1,273 ==00:00:00:07.569 59730== at 0x4C2CFA7: malloc (vg_replace_malloc.c:296) ==00:00:00:07.569 59730== by 0x4E48CA5: rbtree_insertnode (rbtree.c:270) ==00:00:00:07.569 59730== by 0x4E48EB8: rbtree_insert (rbtree.c:299) ==00:00:00:07.569 59730== by 0x40D829: cf_item_add (conffile.c:531) ==00:00:00:07.569 59730== by 0x40D829: cf_item_add (conffile.c:507) ==00:00:00:07.569 59730== by 0x4104AA: cf_item_parse (conffile.c:1085) ==00:00:00:07.569 59730== by 0x410890: cf_section_parse (conffile.c:1197) ==00:00:00:07.569 59730== by 0xF1DE5DE: detail_instantiate (rlm_detail.c:132) ==00:00:00:07.569 59730== by 0x41D38B: find_module_instance (modules.c:620) ==00:00:00:07.569 59730== by 0x41FC63: do_compile_modsingle (modcall.c:1966) ==00:00:00:07.569 59730== by 0x41C69F: load_component_section (modules.c:908) ==00:00:00:07.569 59730== by 0x41CBE1: load_byserver (modules.c:1109) ==00:00:00:07.569 59730== by 0x41DA6C: virtual_servers_load (modules.c:1273) ==00:00:00:07.564 59730== 56 bytes in 1 blocks are still reachable in loss record 792 of 1,273 ==00:00:00:07.564 59730== at 0x4C2CFA7: malloc (vg_replace_malloc.c:296) ==00:00:00:07.564 59730== by 0x424B18: rad_malloc (util.c:347) ==00:00:00:07.564 59730== by 0xF1DE577: detail_instantiate (rlm_detail.c:126) ==00:00:00:07.564 59730== by 0x41D38B: find_module_instance (modules.c:620) ==00:00:00:07.564 59730== by 0x41FC63: do_compile_modsingle (modcall.c:1966) ==00:00:00:07.564 59730== by 0x41C69F: load_component_section (modules.c:908) ==00:00:00:07.564 59730== by 0x41CBE1: load_byserver (modules.c:1109) ==00:00:00:07.564 59730== by 0x41DB14: virtual_servers_load (modules.c:1244) ==00:00:00:07.564 59730== by 0x41E0B7: setup_modules (modules.c:1568) ==00:00:00:07.564 59730== by 0x4097C2: main (radiusd.c:289) -- Best Regards, Yanrui Hu -- *This email may contain or reference confidential information and is intended only for the individual to whom it is addressed. Please refrain from distributing, disclosing or copying this email and the information contained within unless you are the intended recipient. If you received this email in error, please notify us at legal@appannie.com <legal@appannie.com>** immediately and remove it from your system.*