Ok, I've reproduced this now....
Looks like if I have a call in early media, 183 Session Progress, my application gets confused and sends a
nua_bye() instead of nua_cancel() to end the call.

Strangely enough, the stack sends the CANCEL, but then aborts.
Here is some nua and nta debug:

nua(0x108e4d28): signal r_bye
nta: sent CANCEL (100401002) to UDP/10.0.0.233:5060
nta: received 487 Request Terminated for INVITE (100401002)
nta: 487 Request Terminated going to a transaction
nta: sent ACK (100401002) to UDP/10.0.0.233:5060
nta: outgoing_free(0x108d6600)
nua: nua_stack_event: entering
nua(0x108e4d28): r_invite 487 Request Terminated
nua(0x108e4d28): call state changed: proceeding -> terminated
nua: nua_stack_event: entering
nua(0x108e4d28): i_state 487 Request Terminated
nua: nua_stack_event: entering
nua(0x108e4d28): i_terminated 487 Request Terminated
nua(0x108e4d28): removing session usage
nta_leg_destroy(0x108f4230)
nta: received 200 OK for CANCEL (100401002)
nta: 200 OK going to a transaction
nta_outgoing: RTT is 124.181 ms
nua: nua_stack_event: entering
nua(0x108e4d28): r_bye 200 OK
nua(0x108e4d28): call state changed: terminated -> terminated
nua: nua_stack_event: entering
nua(0x108e4d28): i_state 200 to BYE
nua: nua_stack_event: entering
nua(0x108e4d28): i_terminated 200 to BYE
sipuad: nua_dialog.c:328: nua_dialog_usage_remove: Assertion `*at' failed.

And here is some of the backtrace:

Time 22:16:08: sipuad: /lib/libc.so.6(abort+0xd8) [0xfc8b26c]
Time 22:16:08: sipuad: /lib/libc.so.6(__assert_fail+0xf8) [0xfc83014]
Time 22:16:08: sipuad: ./sipuad(nua_dialog_usage_remove+0xbc) [0x100650a8]
Time 22:16:08: sipuad: ./sipuad(nua_stack_process_invite+0x25f8) [0x100706d8]
Time 22:16:08: sipuad: ./sipuad(restart_bye+0x130) [0x10071ab8]
Time 22:16:08: sipuad: ./sipuad(nta_outgoing_find+0xb74) [0x1004cf10]
Time 22:16:08: sipuad: ./sipuad(nta_tpn_by_url+0x1ff4) [0x10041150]
Time 22:16:08: sipuad: ./sipuad(nta_tpn_by_url+0x4b0) [0x1003f60c]
Time 22:16:08: sipuad: ./sipuad(tport_base_deliver+0x44) [0x100c8720]
Time 22:16:08: sipuad: ./sipuad(tport_deliver+0x36c) [0x100c86a0]
Time 22:16:08: sipuad: ./sipuad(tport_recv_event+0x40c) [0x100c8260]


Pekka Pessi wrote:
On 10/7/06, Colin Whittaker <[EMAIL PROTECTED]> wrote:
  
I've seen a few application exits that appear to be from abort() during
bulk call testing.
I only found abort() in
libsofia-sip-ua/su/sofia-sip/htable.h
Should this really be an abort() ?
What would cause this ?
    

assert() also calls abort(), so the exit with abort() you have seen is
probably caused by assert() failing elsewhere.

There is no clear reason to call to abort() in htable_remove()
template, the application has most probably already crashed  in the
previous loop.

  
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Sofia-sip-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Reply via email to