Hi,
I have some questions for you as we have used suspend/continue quite a lot
in the IMS code and don't have any leaks.
Firstly, why are you using pkg_mem for your hash_id and label? Remember
that you will be in 2 different processes in the suspend and continue
portions of the code... so pkg_mem will not work - you should use shm_mem
instead.
Secondly, how are you using top to tell that you have a leak? Kamailio's
memory is internally managed.
Cheers
Jason
On Mon, Jan 13, 2014 at 1:29 PM, Shankar <shankar.rk(a)plintron.com> wrote:
Re-sending without the attachment.
*From:* Shankar [mailto:shankar.rk@plintron.com]
*Sent:* Monday, January 13, 2014 4:57 PM
*To:* 'sr-users(a)lists.sip-router.org'
*Subject:* Regd. t_suspend() and t_continue()
Hi,
We are trying out the t_suspend() and t_continue() in our test setup. We
are facing memory leak ( both shm and pkg as per top command results).
Please find below the scenario,
1) Do a t_newtran()
2) Allocate pkg memory for hashid and label.
3) Call t_suspend()
4) Do t_continue() when async result is available
5) De-allocate pkg memory reserved for hashid and label
6) Do a t_relay() which forwards the sip message to another sip node.
In the step (6) above, we see t_newtran() allocates one more time shared
memory for the same transaction.
We tried t_release() after step (4) to release the transaction as
t_relay() anyways allocates new shared memory. Nothing helped.
Please let me know what are the logs you would require to debug the same.
I am attaching syslog for this run.
Regards,
Shankar
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
*Jason Penton**Senior Manager: Applications and Services**Smile
Communications Pty (Ltd)**Mobile:*+27 (0) 83 283 7000*Skype:*
jason.barry.pentonjason.penton(a)smilecoms.com <name.surname(a)smilecoms.com>
www.smilecoms.com
This email is subject to the disclaimer of Smile Communications at
http://www.smilecoms.com/disclaimer