Freeradius possible memory leak

[Alan DeKok]

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.