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

James Puckett jpuckett at e-c-group.com
Wed Aug 26 16:57:32 CEST 2009


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
>





More information about the sr-users mailing list