Hi Pekka,
As you adviced I check the code,
1) I am locking the nta agent from starting to end.
Also i am no where destroying the irq more than once.
2) while creating the NTATAG_UA(0).
Coming to timeout fires, this may happen either for invite 200 or
non-invite 200.
3) The scenario is as follows,
I am sending the 200OK for invite then the irq should be moved to
completed queue.
But it is still persisting in porceeding queue and thereby failing the
assertion *queue->q_tail for newly coming transaction
(gdb) bt
#0 0x001be7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x002037a5 in raise () from /lib/tls/libc.so.6
#2 0x00205209 in abort () from /lib/tls/libc.so.6
#3 0x001fcd91 in __assert_fail () from /lib/tls/libc.so.6
#4 0x00c5db30 in incoming_create (agent=0x83f7b08, msg=0xa41d76e8,
sip=0xa41d7784, tport=0x83f84e0, tag=0x0) at nta.c:5049
#5 0x00c6d412 in leg_recv (leg=0x83f80c0, msg=0xa41d76e8, sip=0xa41d7784,
tport=0x83f84e0) at nta.c:4659
#6 0x00c6e83d in agent_recv_request (agent=0x83f7b08, msg=0xa41d76e8,
sip=0xa41d7784, tport=0x83f84e0) at nta.c:2955
#7 0x00c6efee in agent_recv_message (agent=0x83f7b08, tport=0x83f84e0,
msg=0xa41d76e8, tport_via=0x83f8a98, now=
{tv_sec = 274877907, tv_usec = 75630}) at nta.c:2722
#8 0x00cc4984 in tport_base_deliver (self=0x0, msg=0xa41d76e8, now={tv_sec
= 3508559559, tv_usec = 75630}) at tport.c:3013
#9 0x00ccb031 in tport_deliver (self=0x83f84e0, msg=0xa41d76e8, next=0x0,
sc=0x0, now={tv_sec = 3508559559, tv_usec = 75630})
at tport.c:3002
#10 0x00ccb2ab in tport_parse (self=0x83f84e0, complete=1, now={tv_sec =
3508559559, tv_usec = 75630}) at tport.c:2919
#11 0x00ccb42d in tport_recv_event (self=0x83f84e0) at tport.c:2861
#12 0x00ccb6d1 in tport_base_wakeup (self=0x83f84e0, events=1) at
tport.c:2763
#13 0x00cbbdac in su_epoll_port_wait_events (self=0x83f7628, tout=81) at
su_epoll_port.c:506
#14 0x00cb9624 in su_base_port_run (self=0x83f7628) at su_base_port.c:342
#15 0x00cb5d75 in su_root_run (self=0x0) at su_port.h:310
#16 0x00cb9fee in su_pthread_port_clone_main (varg=0xbfef0130) at
su_pthread_port.c:321
#17 0x0042a371 in start_thread () from /lib/tls/libpthread.so.0
#18 0x002a3ffe in clone () from /lib/tls/libc.so.6
(gdb) p *queue->q_tail
$9 = (nta_incoming_t *) 0xa400de78
The highlited pointer is the one I am destroying before this assertion
failure happens, after receiving the ACK for that invite.
The same scenario was observed even i dont delete irq up to the time I
receive BYE for that call.
4) When i change the NTATAG_UA(1),
assertion is failing at "irq->irq_status >= 200" while timer H is
expiring.
Please help me how to come out of this problem.
Thanks,
Kiran.
On Sat, Mar 5, 2011 at 4:39 AM, Pekka Pessi <ppe...@gmail.com> wrote:
> Hi Kiran,
>
> 2011/2/26 kiran kumar <g.kiranredd...@gmail.com>:
> > In my application I am destroying the invite transaction (irq) after
> > receiving ack for 200 OK,
> > the ACK transaction (irq) immediately after receiving the ACK.
> > And that of BYE transaction (irq) after sending 200 OK.
> > I am using nta_incoming_destroy(irq) method to do the same.
> > 1) But while i was running the load, Sofia stack is getting crashed with
> the
> > following assertion failure
> > for a completely new request which may be invite or bye,
> > (independent of the transaction for which i am destroying irq in the
> > application).
> > sipng: nta.c:5438: incoming_queue: Assertion `*queue->q_tail ==
> ((void
> > *)0)' failed.
> > Aborted (core dumped)
> > And from the GDB findings I observed that
> > *queue->q_tail points to the irq which i was destroying in my
> > application.
>
> I think you end up destroying the same irq twice. Please doublecheck your
> code..
>
> > 2) From the api documentation it is clear that the destroyed irq should
> be
> > in disposable state up to the timer expires.
> > Please tell me when exactly this timer expires. (i.e., the default
> > timer value )
>
> The non-INVITE irqs are destroyed once the timer J expires, the timer
> J duration is T1x64 (normally, 32 seconds). However, the irq can be
> destroyed earlier if
>
> 1) if the NTA is not in UA mode or
> 2) the response was sent via TCP or TLS
>
> > 3) Is there any way that i can put mutex locks in my application to avoid
> > this synchronization problem.
> > I am suspecting this behavior as bug in stack.
>
> You should protect whole nta_agent_t with a mutex, I'm afraid.
>
> --
> Pekka.Pessi mail at nokia.com
>
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
