Hello,
I am using the sofia-sip library for SUBSCRIBE and NOTIFY
messages.The problem here is When i am putting load of subscribe requests,
the memory goes to 1.5 megabytes and stays there even if i put the load
again with less time difference..
However If i put the load after 1 hour the
Hi,
I am seeing that when I use NUTAG_M_FEATURES to set q value and call the
API nua_register again and again with different q values, memory leak is
happening.
Anyone has seen the same happening ?
Regards
anees k A
--
Hello Pekka,
we have an application based on Sofia SIP 1.12.11 running on linux for powerpc
an instance of the stack for UDP and another instance for TCP.
For service discovery we use a "port scan" tool, that does only a TCP connect()
to the sofia sip server. If we did this with a high freque
Hi,
I am using nta api (nta agent) of sofia sip stack1.12.11 in stateless mode
and facing a problem with memory leak.
When ever I am running the failure scenarios large amount of memory is
leaking,
but there is no memory leak while running positive scenarios of normal
call.
The same is the issue
cc: sofia-sip-devel@lists.sourceforge.net
Subject:Re: [Sofia-sip-devel] Memory leak in timeouts?
Hi Jen,
It doesn't appear this has been fixed yet.
My patch below should still work.
Colin..
Jen Chitty wrote:
Hi,
Did this ever get resolved?
We are running
Hi Jen,
It doesn't appear this has been fixed yet.
My patch below should still work.
Colin..
Jen Chitty wrote:
Hi,
Did this ever get resolved?
We are running into this problem now under 1.12.10.
Once the bug is triggered by changing the system time while a call is
in progress, memory lea
Hi,
Did this ever get resolved?
We are running into this problem now under 1.12.10.
Once the bug is triggered by changing the system time while a call is in
progress, memory leaks on every SIP transaction.
Doing a nua_shutdown causes all the leaked memory to be released, but we
can't afford t
2009/2/27 Della Betta Filippo :
> with the following code (nua_create fails since IP is not valid on my
> machine), I spot two memory leaks of sofia-sip stack.
>
> One is due to the fact that task nua->nua_client is not deinit’ed in case of
> error, the other is due to the fact that nua default han
Dear Pekka,all
with the following code (nua_create fails since IP is not valid on my machine),
I spot two memory leaks of sofia-sip stack.
One is due to the fact that task nua->nua_client is not deinit'ed in case of
error, the other is due to the fact that nua default handle holds a
soa_session_
Dear Pekka,all
with the following code (nua_create fails since IP is not valid on my machine),
I spot two memory leaks of sofia-sip stack.
One is due to the fact that task nua->nua_client is not deinit'ed in case of
error, the other is due to the fact that nua default handle holds a
soa_session_
I've narrowed this down some more, and it seems that if you start an
INVITE in response to receiving a REFER, and then CANCEL the INVITE, you
get nua_i_terminated before the last nua_r_notify. I call
nua_handle_destroy in response to the nua_i_terminated, and completely
ignore the nua_r_notify
Hi,
I noticed that if I do an attended transfer (REFER with Replaces) while
the call from the transferer to the transfer destination has not been
answered yet, and the transferee then terminates the call to the
transferer with a BYE before CANCELing the INVITE with Replaces (to the
transfer de
Re: [Sofia-sip-devel] Memory leak when caller
sends BYE
I'm still seeing this problem with 1.12.10.
:(
--Jen
Michael Jerris
11/25/2008 09:19 AM
To: Jen Chitty
cc: sofia-sip-devel@lists.sourceforge.net
Subject: Re: [Sofia-sip-devel] Memory l
I'm still seeing this problem with 1.12.10.
:(
--Jen
Michael Jerris
11/25/2008 09:19 AM
To: Jen Chitty
cc: sofia-sip-devel@lists.sourceforge.net
Subject:Re: [Sofia-sip-devel] Memory leak when caller
sends BYE
This issue should already be
Jerris <[EMAIL PROTECTED]>
To: Jen Chitty <[EMAIL PROTECTED]>
Cc: sofia-sip-devel@lists.sourceforge.net
Sent: Tuesday, November 25, 2008 11:19:54 AM
Subject: Re: [Sofia-sip-devel] Memory leak when caller sends BYE
This issue should already be fixed in current darcs. In FreeSWITCH
o
This issue should already be fixed in current darcs. In FreeSWITCH
our copy of sofia is currently sync'd with darcs and it is more stable
than 1.12.9 for sure and likely 1.12.8 as well.
Mike
Mike
On Nov 25, 2008, at 11:58 AM, Jen Chitty wrote:
> Hi,
>
> I'm running 1.12.9 and I'm finding
Hi,
I'm running 1.12.9 and I'm finding that my process leaks memory
when it is the caller (sends the INVITE) and it terminates the
call (sends the BYE). However, if the callee terminates the
call, there's no leak.
This is a blocker bug for us, and I don't have a workaround.
I would really apprec
Great. Thanks for your help.
Fabio
On Tue, Aug 5, 2008 at 7:30 PM, Colin Whittaker
<[EMAIL PROTECTED]> wrote:
>
> I think the memory leaks are still there if the Time of Day gets updated too
> far.
> It looks like su_monotime() was added, but the timers are not using it.
>
> I'm testing a fix that
I think the memory leaks are still there if the Time of Day gets
updated too far.
It looks like su_monotime() was added, but the timers are not using it.
I'm testing a fix that changes su_time() and forces it to be monotonic
much like the way the kernel does monotonic time.
The time of day wi
Hi there Pekka,
back in April, I got this response to a question about an assertion
regarding nta timers:
> The code calculating the timeouts has flawed logic, the problem shows
> up if the system clock is adjusted or the load is too high.
I'd like to know if this issue has already been resolved
On 11/30/06, Colin Whittaker <[EMAIL PROTECTED]> wrote:
> I running 1.12.3work4 and I am seeing an occasional memory leak during
> bulk calling tests.
> I assume the path to reproduce this requires some kind of error, but i
> have not isolated that yet.
> The backtrace to all the leaked memory come
I running 1.12.3work4 and I am seeing an occasional memory leak during
bulk calling tests.
I assume the path to reproduce this requires some kind of error, but i
have not isolated that yet.
The backtrace to all the leaked memory comes from
nua_session_usage_shutdown().
I think this happens when
Update..
I think this was fixed sometime last week.
I've been running calls overnight and haven't grown in memory size since
yesterday.
Colin Whittaker wrote:
> I just updated to the latest, and I am seeing a slow memory leak while
> making calls.
> I haven't upgraded my sofia library since ear
I just updated to the latest, and I am seeing a slow memory leak while
making calls.
I haven't upgraded my sofia library since early August. This previous
version had been running continuously since then with no memory leaks.
I haven't traced it down yet, but you should probably hold off on a
r
On 5/17/06, Colin Whittaker <[EMAIL PROTECTED]> wrote:
I think I have traced my growing memory size down to msg headers which
seem to multiply on each REGISTER refresh and SUBSCRIBE refresh.
It appears these headers are removed with msg_header_remove(), but not
freed.
Shouldn't msg_header_remove(
I think I have traced my growing memory size down to msg headers which
seem to multiply on each REGISTER refresh and SUBSCRIBE refresh.
The two I have traced down are allocated in:
msg_header_alloc()
called from:
sip_request-create() and sip_creq_create()
called from:
nta_msg_request_complete()
On 4/20/06, Colin Whittaker <[EMAIL PROTECTED]> wrote:
> Now for my real question,...
> Is there some documentation on how the su memory allocation routines
> keep track of memory ?
There is a short introduction text in
http://sofia-sip.sourceforge.net/refdocs/su/group__su__alloc.html
There seems
On 4/26/06, Colin Whittaker <[EMAIL PROTECTED]> wrote:
> Here are my CVS diffs which fix the handle leaking problem. I also fixed
> a couple of NULL pointer problems.
Thanks Colin.
I merged the auc_authorize() and process_cancel() patches, however,
slightly modified. They are now in darcs at
htt
Here are my CVS diffs which fix the handle leaking problem. I also fixed
a couple of NULL pointer problems.
Index: auth_client.c
===
RCS file:
/cvsroot/sofia-sip/sofia-sip/libsofia-sip-ua/iptsec/auth_client.c,v
retrieving revision
I think I found a memory leak.
It appears memory for handles is not being freed after the
nua_handle_destroy().
The su_block_t sub_ref = 1.
So there appears to be one extra reference which is not being unreferenced.
I've been adding trace code and think I understand what may be going on
here.
While trying to trace down a slow memory leak, and ran across a NULL
pointer exception.
Here is the back trace:
#0 auc_authorize (auc_list=0x10273a2c, msg=0x0, sip=0x10304d34) at
auth_client.c:727
#1 0x10059bb4 in nua_creq_msg (nua=0x10113848, nh=0x10273960,
cr=0x10273994, restart=0, method=s
31 matches
Mail list logo
