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