Szymon Roczniak wrote:
Output with "-m" and some more debugging information:
OK, that helps...
34,944 bytes in 112 blocks are definitely lost in loss record 38 of 44 at 0x4C20809: malloc (vg_replace_malloc.c:149) by 0x4E38DCE: pairalloc (in /usr/lib64/freeradius/libfreeradius-radius-2.1.6.so) by 0x4E39160: pairmake (in /usr/lib64/freeradius/libfreeradius-radius-2.1.6.so) by 0x6A393E1: sql_userparse (in /usr/lib64/freeradius/rlm_sql-2.1.6.so) by 0x6A395D4: sql_getvpdata (in /usr/lib64/freeradius/rlm_sql-2.1.6.so) by 0x6A37741: (within /usr/lib64/freeradius/rlm_sql-2.1.6.so)
Ugh. That line doesn't help. It would be nice to know WHICH function had the problem. Can you re-build the rlm_sql module with debugging symbols? (-g, and DELETE any -O2 flags you find). That way, it will print out line numbers like the following:
by 0x419B2B: modcall (modcall.c:286) by 0x417040: indexed_modcall (modules.c:631)
Here we know exactly which line is being used...
I think the problem is somewhere in our configuration for the sql module as it only affects one particular radius setup we have and not others (all running 2.1.6).
What are the attributes in the DB for the one that leaks memory?
In fact one of our servers has two different sql modules called depending on realm. It shows high memory usage when radius uses one of them (the one tested with the above valgrind output) and it doesn't when the other module is used.
So... the content of the DB is what matters here. Alan DeKok.