Freeradius possible memory leak

Szymon Roczniak simon at
Fri Sep 4 13:57:32 CEST 2009

On Thu, Sep 03, 2009 at 03:02:23PM +0200, Alan DeKok wrote:
>   You should add "-m" to the radiusd command line, so that it will try
> to clean up as much memory as possible before exiting.

Output with "-m" and some more debugging information:

 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/
    by 0x4E39160: pairmake (in /usr/lib64/freeradius/
    by 0x6A393E1: sql_userparse (in /usr/lib64/freeradius/
    by 0x6A395D4: sql_getvpdata (in /usr/lib64/freeradius/
    by 0x6A37741: (within /usr/lib64/freeradius/
    by 0x419B2B: modcall (modcall.c:286)
    by 0x417040: indexed_modcall (modules.c:631)
    by 0x40853A: rad_authenticate (auth.c:554)
    by 0x423D87: radius_handle_request (event.c:3646)
    by 0x41C7C7: request_handler_thread (threads.c:492)
    by 0x5478366: start_thread (in /lib64/

    definitely lost: 34,944 bytes in 112 blocks.
      possibly lost: 3,040 bytes in 10 blocks.
    still reachable: 3,752,939 bytes in 21,575 blocks.
         suppressed: 0 bytes in 0 blocks.

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).

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.

I'm trying to find out what exactly makes the difference in memory usage
between these modules.

> $ valgrind --tool=massif /usr/sbin/radiusd -fm
>   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.

Output is available here:

szymon roczniak
simon at

More information about the Freeradius-Users mailing list