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 <ppessi@gmail.com> wrote:
Hi Kiran,

2011/2/26 kiran kumar <g.kiranreddy4u@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