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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html