Re: Memory leak in FR 2.1.10 and 2.2.0 ?

[Philippe MARASSE]

First, thanks for the two answers.

Le 08/01/2013 14:55, Alan DeKok a écrit :

Philippe MARASSE wrote:

I'm experiencing an infinitely growth of memory footprint of freeradius
process in our production environment (of course, in our test env.
everything goes right).

   That's an issue.

As I cannot reproduce this on my test environment by using eapol_test, I
suspect alcatel frames to trigger a kind of memory leak in freeradius.

   Possible.

I collected different things :
  - pcap of eap-md5 exchange between freeradius and a switch
  - valgrind log on my production server
  - pidstat showing memory usage of freeradius process

   So... what were the results?

As the complete log is pretty big (around 1 Mb) I did not post the entire result (and it exceeds 500kb limit of pastebin), but I can send by mail valgrind log, pcap and other possibly useful things.

   Did valgrind say anything useful?

I've never used valgrind before but here's some extract that I've think relevant and the summary :

==00:01:17:29.869 24818==    at 0x4023F50: malloc (vg_replace_malloc.c:236)
==00:01:17:29.869 24818==    by 0x806B2EC: rad_malloc (in /usr/sbin/freeradius)
==00:01:17:29.869 24818==    by 0x47FBBE5: ???
==00:01:17:29.869 24818==    by 0x47F9A15: ???
==00:01:17:29.869 24818==    by 0x47F8E99: ???
==00:01:17:29.869 24818==    by 0x8065C0A: modcall (in /usr/sbin/freeradius)
==00:01:17:29.869 24818==    by 0x8061CDF: indexed_modcall (in 
/usr/sbin/freeradius)
==00:01:17:29.869 24818==    by 0x80620FB: module_authenticate (in 
/usr/sbin/freeradius)
==00:01:17:29.869 24818==    by 0x804FFAD: rad_authenticate (in 
/usr/sbin/freeradius)
==00:01:17:29.869 24818==    by 0x8074089: radius_handle_request (in 
/usr/sbin/freeradius)
==00:01:17:29.869 24818==    by 0x806AAF5: ??? (in /usr/sbin/freeradius)
==00:01:17:29.869 24818==    by 0x4081954: start_thread (pthread_create.c:300)
==00:01:17:29.869 24818==
==00:01:17:29.869 24818== LEAK SUMMARY:
==00:01:17:29.869 24818==    definitely lost: 51,904 bytes in 382 blocks
==00:01:17:29.869 24818==    indirectly lost: 26,398,375 bytes in 15,411 blocks
==00:01:17:29.869 24818==      possibly lost: 2,145,153 bytes in 1,719 blocks
==00:01:17:29.869 24818==    still reachable: 40,292 bytes in 2,493 blocks
==00:01:17:29.869 24818==         suppressed: 0 bytes in 0 blocks
==00:01:17:29.869 24818== Reachable blocks (those to which a pointer was found) 
are not shown.
==00:01:17:29.869 24818== To see them, rerun with: --leak-check=full 
--show-reachable=yes
==00:01:17:29.869 24818==
==00:01:17:29.869 24818== For counts of detected and suppressed errors, rerun 
with: -v
==00:01:17:29.869 24818== Use --track-origins=yes to see where uninitialised 
values come from


I don't know if I've missed something as there's some "???" in the call stacks ?

==00:01:17:29.869 24818== 10,033,120 (16,016 direct, 10,017,104 indirect) bytes in 143 blocks are definitely lost in loss record 723 of 724 ==00:01:17:29.869 24818== ERROR SUMMARY: 493967 errors from 561 contexts (suppressed: 97 from 12)

   The main issue is that the memory might not be leaked.  It might be
referenced, but unused.  That's much harder to track down.

Rgds.

--
Philippe MARASSE

Service Informatique - Centre Hospitalier Henri Laborit
BP 587 - 370 avenue Jacques Coeur
86021 Poitiers Cedex
Tel : 05.49.44.57.19

smime.p7s
Description: Signature cryptographique S/MIME

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html