Oh. And BTW. This is with 1.5.2-tls.

James Puckett - Engineers' Consulting Group Phone 229-316-0012 - Fax 229-316-1490

On Aug 26, 2009, at 10:13 AM, James Puckett wrote:

I have posted the log to http://cpem.stage2.net/kamailio-mem.log. This log contains 2000 calls of memory information.

James Puckett - Engineers' Consulting Group Phone 229-316-0012 - Fax 229-316-1490

On Aug 26, 2009, at 7:31 AM, Daniel-Constantin Mierla wrote:

...

Hello,

On 26.08.2009 2:07 Uhr, James Puckett wrote:

...

I have followed a bit of the discussions regarding the problems with memory management between the perl modules and the core kamailio software.

that is when calling functions exported by modules that need fixup. For append_branch() should not be the case.

...

I need to get append_branch working from within the perl module so that it doesn't cause a memory leak. It's been a while since I did any serious straight C programming, but if someone can point me to the correct way to handle memory allocated with the module so that it gets freed in the core I'd be glad to take this problem on.

Specifically, I'm using something that looks like:

$m->append_branch("<sip:".$cdpn."@".$peers{$_}."?From=%3Csip:". $sourcenumber."@".$destIp."%3E;tag=".$fromtag.">", $qval);

This leaves about 190 bytes per call unfreed.

Do you have the memory log? That will help to troubleshoot.

Cheers, Daniel

-- Daniel-Constantin Mierla

• http://www.asipto.com/

---

Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

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

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