Freeradius possible memory leak

Alan DeKok aland at deployingradius.com
Thu Sep 3 15:02:23 CEST 2009


Szymon Roczniak wrote:
> I've followed the advise from the previous thread and run radiusd under
> valgrind for around 10-15 minutes with some generated traffic and
> the output is:
> 
> valgrind --tool=memcheck --leak-check=full /usr/sbin/radiusd -f

  You should add "-m" to the radiusd command line, so that it will try
to clean up as much memory as possible before exiting.

> [..]
> ==11730== LEAK SUMMARY:
> ==11730==    definitely lost: 8,705,168 bytes in 27,890 blocks.
> ==11730==    indirectly lost: 8,351,440 bytes in 26,598 blocks.
> ==11730==      possibly lost: 17,072 bytes in 56 blocks.
> ==11730==    still reachable: 118,598 bytes in 2,467 blocks.
> ==11730==         suppressed: 0 bytes in 0 blocks.
> ==11730== Reachable blocks (those to which a pointer was found) are not shown.
> 
> Is there anything else I can do to track it down and possibly fix the problem?

$ valgrind --tool=massif /usr/sbin/radiusd -fm
...
(make it exit cleanly)

$ ms_print massif* > radiusd.txt

  That will print out where it *allocates* memory.  This helps to catch
cases where the memory isn't leaked, but also isn't being free'd.

> Would setting up max_request_per_server to something else than 0 be a good
> workaround for it in the meantime?

  No.

  Alan DeKok.



More information about the Freeradius-Users mailing list