Hi, I try to test with the latest version of freeradius in git 2.x.x and still get the same behavior. Seems the envp variable in radius_exec_program function (exec.c) not clean?
PS: my system is 64bit. valgrind log below: ==3043== 13,852 (368 direct, 13,484 indirect) bytes in 2 blocks are definitely lost in loss record 622 of 625 ==3043== at 0x4C23224: malloc (vg_replace_malloc.c:270) ==3043== by 0x5D9A1E1: CRYPTO_malloc (in /lib/libcrypto.so.0.9.8) ==3043== by 0x5B1CD96: ssl_cert_new (in /lib/libssl.so.0.9.8) ==3043== by 0x5B1AC0A: SSL_CTX_new (in /lib/libssl.so.0.9.8) ==3043== by 0x8265DFB: ??? ==3043== by 0x8266817: ??? ==3043== by 0x783D99F: ??? ==3043== by 0x783C802: ??? ==3043== by 0x41F921: find_module_instance (modules.c:612) ==3043== by 0x424712: do_compile_modsingle (modcall.c:1924) ==3043== by 0x424D47: compile_modsingle (modcall.c:2053) ==3043== by 0x420269: load_component_section (modules.c:900) ==3043== ==3043== 62,400 (31,200 direct, 31,200 indirect) bytes in 100 blocks are definitely lost in loss record 624 of 625 ==3043== at 0x4C23224: malloc (vg_replace_malloc.c:270) ==3043== by 0x4E48C6C: pairalloc (valuepair.c:72) ==3043== by 0x4E4B3A9: pairmake (valuepair.c:1526) ==3043== by 0x4E4B900: pairread (valuepair.c:1736) ==3043== by 0x4E4BC71: userparse (valuepair.c:1850) ==3043== by 0x4128E8: radius_exec_program (exec.c:456) ==3043== by 0x6C1D5F5: ??? ==3043== by 0x6C1D71B: ??? ==3043== by 0x421DE3: call_modsingle (modcall.c:304) ==3043== by 0x422BF1: modcall (modcall.c:684) ==3043== by 0x41FDF1: indexed_modcall (modules.c:742) ==3043== by 0x421835: module_post_auth (modules.c:1664) ==3043== ==3043== 62,400 bytes in 200 blocks are definitely lost in loss record 625 of 625 ==3043== at 0x4C23224: malloc (vg_replace_malloc.c:270) ==3043== by 0x4E48C6C: pairalloc (valuepair.c:72) ==3043== by 0x4E4B3A9: pairmake (valuepair.c:1526) ==3043== by 0x4E4B900: pairread (valuepair.c:1736) ==3043== by 0x4E4BC71: userparse (valuepair.c:1850) ==3043== by 0x4128E8: radius_exec_program (exec.c:456) ==3043== by 0x6C1D5F5: ??? ==3043== by 0x421DE3: call_modsingle (modcall.c:304) ==3043== by 0x422BF1: modcall (modcall.c:684) ==3043== by 0x41FDF1: indexed_modcall (modules.c:742) ==3043== by 0x4217ED: module_pre_proxy (modules.c:1647) ==3043== by 0x436979: successfully_proxied_request (event.c:2248) ==3043== ==3043== LEAK SUMMARY: ==3043== definitely lost: 95,310 bytes in 328 blocks ==3043== indirectly lost: 54,672 bytes in 727 blocks ==3043== possibly lost: 0 bytes in 0 blocks ==3043== still reachable: 73,867 bytes in 2,473 blocks ==3043== suppressed: 0 bytes in 0 blocks ==3043== Reachable blocks (those to which a pointer was found) are not shown. ==3043== To see them, rerun with: --leak-check=full --show-reachable=yes ==3043== ==3043== For counts of detected and suppressed errors, rerun with: -v ==3043== Use --track-origins=yes to see where uninitialised values come from ==3043== ERROR SUMMARY: 986273 errors from 479 contexts (suppressed: 201 from 43) On Wed, Mar 6, 2013 at 4:08 PM, kao quadrantx <quadra...@gmail.com> wrote: > Hi, > > i got the same issue in freeradius memory issue > http://freeradius.1045715.n5.nabble.com/Memory-leak-in-FR-2-1-10-and-2-2-0-tt5717545.html#a5717576 > > My test ENV: > > eapol_test with md5 to do AUTH (client) ---------> freeradius 2.2.0 to > proxy the client request (proxy) -----------------------------> freeradius > 2.2.0 > > More request more memory (VmRSS) consumed by radiusd (proxy), and the > daemon performance will also down. > > And i use valgrind to log this: > > ==14786== > ==14786== HEAP SUMMARY: > ==14786== in use at exit: 172,724 bytes in 2,819 blocks > ==14786== total heap usage: 43,388 allocs, 40,569 frees, 5,148,356 bytes > allocated > ==14786== > ==14786== 4 bytes in 1 blocks are definitely lost in loss record 1 of 527 > ==14786== at 0x4C23224: malloc (vg_replace_malloc.c:270) > ==14786== by 0x633A061: strdup (in /lib/libc-2.9.so) > ==14786== by 0x40E641: cf_item_parse (conffile.c:953) > ==14786== by 0x41BF4A: listen_parse (listen.c:1953) > ==14786== by 0x41C5CA: listen_init (listen.c:2174) > ==14786== by 0x438A36: radius_event_init (event.c:3648) > ==14786== by 0x425971: main (radiusd.c:332) > ==14786== > ==14786== 5 bytes in 1 blocks are definitely lost in loss record 3 of 527 > ==14786== at 0x4C23224: malloc (vg_replace_malloc.c:270) > ==14786== by 0x633A061: strdup (in /lib/libc-2.9.so) > ==14786== by 0x40E641: cf_item_parse (conffile.c:953) > ==14786== by 0x40EE5C: cf_section_parse (conffile.c:1173) > ==14786== by 0x41DE96: switch_users (mainconfig.c:614) > ==14786== by 0x41E6B9: read_mainconfig (mainconfig.c:874) > ==14786== by 0x4257CD: main (radiusd.c:263) > ==14786== > ==14786== 368 (136 direct, 232 indirect) bytes in 1 blocks are definitely > lost in loss record 477 of 527 > ==14786== at 0x4C23224: malloc (vg_replace_malloc.c:270) > ==14786== by 0x42B8AF: rad_malloc (util.c:347) > ==14786== by 0x41B9BF: listen_alloc (listen.c:1735) > ==14786== by 0x41BC83: proxy_new_listener (listen.c:1838) > ==14786== by 0x43D514: home_server_create_callback (realms.c:2254) > ==14786== by 0x4E45CFA: WalkNodeInOrder (rbtree.c:551) > ==14786== by 0x4E45E78: rbtree_walk (rbtree.c:603) > ==14786== by 0x43D564: home_server_create_listeners (realms.c:2280) > ==14786== by 0x41CA15: listen_init (listen.c:2323) > ==14786== by 0x438A36: radius_event_init (event.c:3648) > ==14786== by 0x425971: main (radiusd.c:332) > ==14786== > ==14786== 6,800 bytes in 25 blocks are possibly lost in loss record 522 of > 527 > ==14786== at 0x4C252BE: calloc (vg_replace_malloc.c:593) > ==14786== by 0x40104BE: _dl_allocate_tls (in /lib/ld-2.9.so) > ==14786== by 0x5491C14: pthread_create (in /lib/libpthread-2.9.so) > ==14786== by 0x42A611: spawn_thread (threads.c:663) > ==14786== by 0x42AB1B: thread_pool_init (threads.c:862) > ==14786== by 0x438803: radius_event_init (event.c:3575) > ==14786== by 0x425971: main (radiusd.c:332) > ==14786== > ==14786== 37,440 (18,720 direct, 18,720 indirect) bytes in 60 blocks are > definitely lost in loss record 526 of 527 > ==14786== at 0x4C23224: malloc (vg_replace_malloc.c:270) > ==14786== by 0x4E488C8: pairalloc (valuepair.c:72) > ==14786== by 0x4E4AFFC: pairmake (valuepair.c:1526) > ==14786== by 0x4E4B553: pairread (valuepair.c:1736) > ==14786== by 0x4E4B8C4: userparse (valuepair.c:1850) > ==14786== by 0x412A7F: radius_exec_program (exec.c:583) > ==14786== by 0x6C1A5F5: ??? > ==14786== by 0x6C1A71B: ??? > ==14786== by 0x421CAB: call_modsingle (modcall.c:304) > ==14786== by 0x422AD5: modcall (modcall.c:686) > ==14786== by 0x41FCB8: indexed_modcall (modules.c:740) > ==14786== by 0x4216FC: module_post_auth (modules.c:1662) > ==14786== > ==14786== 37,440 bytes in 120 blocks are definitely lost in loss record > 527 of 527 > ==14786== at 0x4C23224: malloc (vg_replace_malloc.c:270) > ==14786== by 0x4E488C8: pairalloc (valuepair.c:72) > ==14786== by 0x4E4AFFC: pairmake (valuepair.c:1526) > ==14786== by 0x4E4B553: pairread (valuepair.c:1736) > ==14786== by 0x4E4B8C4: userparse (valuepair.c:1850) > ==14786== by 0x412A7F: radius_exec_program (exec.c:583) > ==14786== by 0x6C1A5F5: ??? > ==14786== by 0x421CAB: call_modsingle (modcall.c:304) > ==14786== by 0x422AD5: modcall (modcall.c:686) > ==14786== by 0x41FCB8: indexed_modcall (modules.c:740) > ==14786== by 0x4216B4: module_pre_proxy (modules.c:1645) > ==14786== by 0x435F6E: successfully_proxied_request (event.c:2230) > ==14786== > ==14786== LEAK SUMMARY: > ==14786== definitely lost: 56,305 bytes in 183 blocks > ==14786== indirectly lost: 18,952 bytes in 63 blocks > ==14786== possibly lost: 6,800 bytes in 25 blocks > ==14786== still reachable: 90,667 bytes in 2,548 blocks > ==14786== suppressed: 0 bytes in 0 blocks > ==14786== Reachable blocks (those to which a pointer was found) are not > shown. > ==14786== To see them, rerun with: --leak-check=full --show-reachable=yes > ==14786== > ==14786== For counts of detected and suppressed errors, rerun with: -v > ==14786== Use --track-origins=yes to see where uninitialised values come > from > ==14786== ERROR SUMMARY: 715158 errors from 470 contexts (suppressed: 201 > from 43) >
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html