<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Thanks for the info. I will try valgrind later today.<br>
<br>
As I wrote before, the memory leak seems to be present even before<br>
I introduced the new thread-depended mechanism for radius.<br>
I will try troubleshoot it there, instead of troubleshooting my patch,
so<br>
that it gets solved on both.<br>
<br>
Rupa Schomaker (lists) wrote:
<blockquote cite="mid:499351D6.8040906@lists.rupa.com" type="cite">
<pre wrap="">On 2/10/2009 10:34 AM, Apostolos Pantsiopoulos wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
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
<a class="moz-txt-link-abbreviated" href="mailto:Freeswitch-dev@lists.freeswitch.org">Freeswitch-dev@lists.freeswitch.org</a>
<a class="moz-txt-link-freetext" href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a>
UNSUBSCRIBE:<a class="moz-txt-link-freetext" href="http://lists.freeswitch.org/mailman/options/freeswitch-dev">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a>
<a class="moz-txt-link-freetext" href="http://www.freeswitch.org">http://www.freeswitch.org</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: <a class="moz-txt-link-abbreviated" href="mailto:regs@kinetix.gr">regs@kinetix.gr</a>
------------------------------------------- </pre>
</body>
</html>