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