Memory leak in FR 2.1.10 and 2.2.0 ?

[Philippe MARASSE]

First, thanks for the two answers.

Le 08/01/2013 14:55, Alan DeKok a écrit :
> Philippe MARASSE wrote:
>> I'm experiencing an infinitely growth of memory footprint of freeradius
>> process in our production environment (of course, in our test env.
>> everything goes right).
>    That's an issue.
>
>> As I cannot reproduce this on my test environment by using eapol_test, I
>> suspect alcatel frames to trigger a kind of memory leak in freeradius.
>    Possible.
>
>> I collected different things :
>>   - pcap of eap-md5 exchange between freeradius and a switch
>>   - valgrind log on my production server
>>   - pidstat showing memory usage of freeradius process
>    So... what were the results?
As the complete log is pretty big (around 1 Mb) I did not post the entire result (and it 
exceeds 500kb limit of pastebin), but I can send by mail valgrind log, pcap and other 
possibly useful things.
>
>    Did valgrind say anything useful?
I've never used valgrind before but here's some extract that I've think relevant and the 
summary :

==00:01:17:29.869 24818== 10,033,120 (16,016 direct, 10,017,104 indirect) bytes in 143 
blocks are definitely lost in loss record 723 of 724
==00:01:17:29.869 24818==    at 0x4023F50: malloc (vg_replace_malloc.c:236)
==00:01:17:29.869 24818==    by 0x806B2EC: rad_malloc (in /usr/sbin/freeradius)
==00:01:17:29.869 24818==    by 0x47FBBE5: ???
==00:01:17:29.869 24818==    by 0x47F9A15: ???
==00:01:17:29.869 24818==    by 0x47F8E99: ???
==00:01:17:29.869 24818==    by 0x8065C0A: modcall (in /usr/sbin/freeradius)
==00:01:17:29.869 24818==    by 0x8061CDF: indexed_modcall (in /usr/sbin/freeradius)
==00:01:17:29.869 24818==    by 0x80620FB: module_authenticate (in /usr/sbin/freeradius)
==00:01:17:29.869 24818==    by 0x804FFAD: rad_authenticate (in /usr/sbin/freeradius)
==00:01:17:29.869 24818==    by 0x8074089: radius_handle_request (in /usr/sbin/freeradius)
==00:01:17:29.869 24818==    by 0x806AAF5: ??? (in /usr/sbin/freeradius)
==00:01:17:29.869 24818==    by 0x4081954: start_thread (pthread_create.c:300)
==00:01:17:29.869 24818==
==00:01:17:29.869 24818== LEAK SUMMARY:
==00:01:17:29.869 24818==    definitely lost: 51,904 bytes in 382 blocks
==00:01:17:29.869 24818==    indirectly lost: 26,398,375 bytes in 15,411 blocks
==00:01:17:29.869 24818==      possibly lost: 2,145,153 bytes in 1,719 blocks
==00:01:17:29.869 24818==    still reachable: 40,292 bytes in 2,493 blocks
==00:01:17:29.869 24818==         suppressed: 0 bytes in 0 blocks
==00:01:17:29.869 24818== Reachable blocks (those to which a pointer was found) are not shown.
==00:01:17:29.869 24818== To see them, rerun with: --leak-check=full --show-reachable=yes
==00:01:17:29.869 24818==
==00:01:17:29.869 24818== For counts of detected and suppressed errors, rerun with: -v
==00:01:17:29.869 24818== Use --track-origins=yes to see where uninitialised values come from
==00:01:17:29.869 24818== ERROR SUMMARY: 493967 errors from 561 contexts (suppressed: 97 
from 12)

I don't know if I've missed something as there's some "???" in the call stacks ?

>    The main issue is that the memory might not be leaked.  It might be
> referenced, but unused.  That's much harder to track down.

Rgds.

-- 
Philippe MARASSE

Service Informatique - Centre Hospitalier Henri Laborit
BP 587 - 370 avenue Jacques Coeur
86021 Poitiers Cedex
Tel : 05.49.44.57.19


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4539 bytes
Desc: Signature cryptographique S/MIME
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20130108/0013fe41/attachment-0001.bin>