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