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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
