[Kamailio-Users] Perl module and memory leak in append_branch
Daniel-Constantin Mierla
miconda at gmail.com
Wed Aug 26 20:40:05 CEST 2009
On 26.08.2009 20:18 Uhr, Daniel-Constantin Mierla wrote:
> 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.
I committed on SVN the new version using the C appen_brnach() -- get the
branch 1.5 and let me know if works ok.
Thanks,
Daniel
>
> 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/
More information about the Users
mailing list