[Kamailio-Users] Perl module and memory leak in append_branch

[Daniel-Constantin Mierla]

hmm, right, I overlooked the fact the perl module uses mk_action() at 
runtime since there is a dedicated C function for append_branch(). Your 
patch should fix the leak, but is better to update to use the dedicated 
function. I will do a patch for that.

Thanks,
Daniel

On 26.08.2009 17:57 Uhr, James Puckett wrote:
> This is the entire routing portion of the configuration.  So the ~2000 
> mk_actions that a dumped on exit are significantly higher than I would 
> have expected.  Also, in previous dumps I was able to track a good 
> number of these frags back to where they were allocated and they all 
> appear to be coming from the append_branch in the perl module.
>
>
> It looks like a pkg_free() is missing in modules/perl/openserxs.c" @ 
> 1763.
>
>
>                 if (act) {
>                         RETVAL = do_action(act, msg);
> +++            pkg_free(act);
>                 } else {
>                         RETVAL = -1;
>                 }
>
>
> Thoughts?
>
>
> ===
>
> # main request routing logic
>
> route{
>         #initial requests
>         if(is_method("OPTIONS")) {
>                 # send reply for each options request
>                 sl_send_reply("200", "ok");
>
>                 log("OPTIONS");
>                 exit;
>         }
>
>         route(1);
> }
>
>
> route[1] {
>
>
>         if (is_method("INVITE")) {
>                 resetflag(9);
>                 perl_exec("routecall");
>
>
>                 if (isflagset(9)) {
>                         sl_send_reply("302", "Redirect");
>                 } else {
>                         sl_send_reply("404", "Not Found");
>                 }
>         };
>
>         exit;
> }
> ===
>
>
>
>
> James Puckett - Engineers' Consulting Group
> Phone 229-316-0012 - Fax 229-316-1490
>
>
>
>
> On Aug 26, 2009, at 10:39 AM, Daniel-Constantin Mierla wrote:
>
>> From the log I see that at shutdown, only pkg allocated at startup is 
>> still allocated (e.g., mk_action is used to create the cfg tree which 
>> is executed at runtime).
>>
>> If you can point me exact part of log that intrigues you, I will have 
>> a look. Other option, if you get out of memory (and not only) from a 
>> specific pid, send a SIGUSR1 to that pid and you will get the mem 
>> status -- make that part available somewhere for investigation.
>>
>> Cheers,
>> Daniel
>>
>

-- 
Daniel-Constantin Mierla
* http://www.asipto.com/