[Freeswitch-dev] mod_radius_cdr behavior and questions [first patch created]

[Apostolos Pantsiopoulos]

Thanks for the info. I will try valgrind later today.

As I wrote before, the memory leak seems to be present even before
I introduced the new thread-depended mechanism for radius.
I will try troubleshoot it there, instead of troubleshooting my patch, so
that it gets solved on both.

Rupa Schomaker (lists) wrote:
> On 2/10/2009 10:34 AM, Apostolos Pantsiopoulos wrote:
>   
>>> P.S. If someone is eager to work with me in solving the possible
>>> memory leak please contact me directly or through the list. I am not
>>> a very good c coder and debugging c is somewhat new to me. So, any
>>> help would be welcomed.
>>>       
>
> If you jump on irc I can help you with valgrind.  It helped me track
> down some memory leaks in mod_lcr.
>
> The basic idea is to run valgrind on your freeswitch binary:
>
> valgrind --tool=memcheck --log-file-exactly=vg.log --leak-check=full
> --leak-resolution=high --show-reachable=yes bin/freeswitch -vg
>
> (all one line).  I'm running a diff version of valgrind, so the log file
> argument is --log-file=vg.log not --log-file-exactly.
>
> The methodology I used was to:
>
> 1) start freeswitch with the module unloaded
> 2) load the module
> 3) run some simple test cases (don't hit it with sipp right away)
> 4) unload the module
> 5) then shutdown freeswitch
>
> You'll see "leaks" from sofia and some other modules.  But don't focus
> on those.  Search the logfile for your module.  In my case, I looked for
> "lcr".
>
> valgrind will show you allocations that weren't properly freed.
>
>
> I completely moved mod_lcr to using the pool based allocator.  This
> greatly simplified memory management.  If everything is allocated in the
> pool, you can free once the pool and everything gets freed.  You do need
> to consider the lifecycle of your pool though.  In your case, you are
> tossing copies to another thread and that thread is long running.  So,
> you either need to periodically free your pool (every N log entries
> processed) or forget the pool and free per entry.
>
> If doing every N log entries -- keep in mind locking (so you don't try
> to free the pool while the session thread is allocating memory from your
> pool to copy the event into).  Also, you probably want two pools.  One
> for your log lived objects (config data, connection to radius, etc) and
> one for short lived objects (the events).
>
> I think I typed too much, jump over to irc when you get a chance.  I'm
> quite busy today, but in general can help.
>
> --Rupa
>
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>   


-- 
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: regs at kinetix.gr
------------------------------------------- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090212/f20cd973/attachment-0001.html