freeradius memory leak after use detail file
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.*
On 3 Feb 2015, at 14:30, Yanrui Hu <yhu@appannie.com> wrote:
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?
No idea. significant amounts of code has changed between 2.2.6 and 3.0.6 (there is no 3.2.x). Test it an see. -Arran FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Feb 3, 2015, at 2:30 AM, Yanrui Hu <yhu@appannie.com> wrote:
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?
The information you posted doesn’t show a leak in the detail file reader. The leak here is in the detail file writer. It leaks memory *once*, when the module starts up. And never again. Can you reproduce the problem with a simplified configuration? Odds are that the problem isn’t where you expect, but is somewhere else. Alan DeKok.
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Yanrui Hu