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.