26 Aug
2009
26 Aug
'09
4:07 a.m.
I have followed a bit of the discussions regarding the problems with
memory management between the perl modules and the core kamailio
software.
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."(a)".$destIp."%3E;tag=".$fromtag.">"=".$fromtag.">",
$qval);
This leaves about 190 bytes per call unfreed.
Thanks.
James Puckett - Engineers' Consulting Group
Phone 229-316-0012 - Fax 229-316-1490
26 Aug
26 Aug
4:31 p.m.
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/
7:13 p.m.
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."(a)".$destIp."%3E;tag=".$fromtag.">"=".$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/
7:25 p.m.
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:
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users 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."(a)".$destIp."%3E;tag=".$fromtag.">"=".$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/
7:39 p.m.
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 17:25 Uhr, James Puckett wrote:
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:
--
Daniel-Constantin Mierla
* http://www.asipto.com/
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:
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users 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/
7:57 p.m.
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
10:18 p.m.
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:
--
Daniel-Constantin Mierla
* http://www.asipto.com/
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
11:40 p.m.
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:
--
Daniel-Constantin Mierla
* http://www.asipto.com/
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
5367
days inactive
5368
days old
7 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
James Puckett