freeradius memory leak after use detail file

[Yanrui Hu]

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 at appannie.com 
<legal at appannie.com>** immediately and remove it from your system.*