[Home]

Summary:ASTERISK-17091: Problem on TRANSFER using SNOM transfer Button
Reporter:Andrea Cristofanini (hydrolife)Labels:
Date Opened:2010-12-10 11:22:04.000-0600Date Closed:2012-02-13 10:42:15.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) FULL-GDB-BT.txt
( 1) FULL-GDB-Thread.txt
Description:(Phone A) calls (Phone B). If phone B tries to Transfer (With SNOM Method - REFER), asterisk freeze (SIP Module). Asterisk doesn't receive or send any SIP Packet.
This does not happens if (Phone A) calls (Phone B) AND phone A tries to Transfer (With SNOM Method - REFER)

Necessary to restart asterisk because any sip reload doesn't work.(SIP is freezed)

Test with asterisk 1.8.0 and asterisk 1.8.1  this was working on asterisk 1.6.2.X
Comments:By: Birger "WIMPy" Harzenetter (wimpy) 2010-12-10 16:35:27.000-0600

NAK

Tried both blind and attended transfer, both using UDP and TLS.
Works as expected for me.

Asterisk trunk form a few days ago and Snom 360 FW 8.4.22 (beta).
By: Andrea Cristofanini (hydrolife) 2010-12-15 04:50:19.000-0600

The problem persists on asterisk-1.8.1 and also on  SVN-trunk-r298137M x86_64 Fedora 13.

The Blind & Attended Transfer works, but does not works the transfer with SNOM Method - REFER- (pressing Transfer button on the SNOM)

Tested with Stable snom firmware & Last beta snom firmware too, Snom 300 FW 8.4.22 (beta).

Attached :
-FULL-GDB-BT.txt  ----> Full BT from gdb attached to asterisk pid.
-FULL-GDB-Thread.txt ----> Full BT thread showing deadlocks.

Lokks that this issue can be related to :
18468 (Astra Transfer)
18204 (Deadlock 1.8 with multiple sip channel)


By: Russell Bryant (russell) 2010-12-16 14:39:47.000-0600

Can you please build Asterisk with DONT_OPTIMIZE and DEBUG_THREADS enabled in menuselect?  Then, when it locks up, run "core show locks" at the Asterisk CLI.  Post the output here.
By: Andrea Cristofanini (hydrolife) 2010-12-17 03:40:17.000-0600

Here there is the output of command "core show locks" using asterisk 1.8.1 :

ephone*CLI> core show locks

=======================================================================
=== Currently Held Locks ==============================================
=======================================================================
===
=== <pending> <lock#> (<file>): <lock type> <line num> <function> <lock name> <lock addr> (times locked)
===
=== Thread ID: 140323091724048 (do_monitor           started at [24414] chan_sip.c restart_monitor())
=== ---> Lock #0 (chan_sip.c): MUTEX 23908 handle_request_do &netlock 0x7f9f855908c0 (1)
       /usr/sbin/asterisk(ast_bt_get_addresses+0x1d) [0x4e17a0]
       /usr/sbin/asterisk(__ast_pthread_mutex_lock+0xaf) [0x4da979]
       /usr/lib/asterisk/modules/chan_sip.so(+0x7c24c) [0x7f9f8534524c]
       /usr/lib/asterisk/modules/chan_sip.so(+0x7c041) [0x7f9f85345041]
       /usr/sbin/asterisk(ast_io_wait+0x1c4) [0x4d4dc4]
       /usr/lib/asterisk/modules/chan_sip.so(+0x7de25) [0x7f9f85346e25]
       /usr/sbin/asterisk() [0x55c457]
       /lib64/libpthread.so.0() [0x3983207761]
       /lib64/libc.so.6(clone+0x6d) [0x3982ae14fd]
=== ---> Lock #1 (chan_sip.c): MUTEX 7464 find_call sip_pvt_ptr 0x7f9f28006700 (1)
       /usr/sbin/asterisk(ast_bt_get_addresses+0x1d) [0x4e17a0]
       /usr/sbin/asterisk(__ast_pthread_mutex_lock+0xaf) [0x4da979]
       /usr/sbin/asterisk(__ao2_lock+0x5a) [0x44097c]
       /usr/lib/asterisk/modules/chan_sip.so(+0x2895f) [0x7f9f852f195f]
       /usr/lib/asterisk/modules/chan_sip.so(+0x7c266) [0x7f9f85345266]
       /usr/lib/asterisk/modules/chan_sip.so(+0x7c041) [0x7f9f85345041]
       /usr/sbin/asterisk(ast_io_wait+0x1c4) [0x4d4dc4]
       /usr/lib/asterisk/modules/chan_sip.so(+0x7de25) [0x7f9f85346e25]
       /usr/sbin/asterisk() [0x55c457]
       /lib64/libpthread.so.0() [0x3983207761]
       /lib64/libc.so.6(clone+0x6d) [0x3982ae14fd]
=== ---> Lock #2 (chan_sip.c): MUTEX 23922 handle_request_do p->owner 0x7f9f2800d9e0 (1)
       /usr/sbin/asterisk(ast_bt_get_addresses+0x1d) [0x4e17a0]
       /usr/sbin/asterisk(__ast_pthread_mutex_trylock+0xaf) [0x4dacfc]
       /usr/sbin/asterisk(__ao2_trylock+0x5a) [0x440a3e]
       /usr/lib/asterisk/modules/chan_sip.so(+0x7c37b) [0x7f9f8534537b]
       /usr/lib/asterisk/modules/chan_sip.so(+0x7c041) [0x7f9f85345041]
       /usr/sbin/asterisk(ast_io_wait+0x1c4) [0x4d4dc4]
       /usr/lib/asterisk/modules/chan_sip.so(+0x7de25) [0x7f9f85346e25]
       /usr/sbin/asterisk() [0x55c457]
       /lib64/libpthread.so.0() [0x3983207761]
       /lib64/libc.so.6(clone+0x6d) [0x3982ae14fd]
=== -------------------------------------------------------------------
===
=== Thread ID: 140322650359568 (handle_tcptls_connection started at [  274] tcptls.c ast_tcptls_server_root())
=== ---> Waiting for Lock #0 (manager.c): MUTEX 3132 action_status c 0x7f9f2800d9e0 (1)
       /usr/sbin/asterisk(ast_bt_get_addresses+0x1d) [0x4e17a0]
       /usr/sbin/asterisk(__ast_pthread_mutex_lock+0xaf) [0x4da979]
       /usr/sbin/asterisk(__ao2_lock+0x5a) [0x44097c]
       /usr/sbin/asterisk() [0x4e8e35]
       /usr/sbin/asterisk() [0x4ee08e]
       /usr/sbin/asterisk() [0x4ee660]
       /usr/sbin/asterisk() [0x4ee9c9]
       /usr/sbin/asterisk() [0x54b9da]
       /usr/sbin/asterisk() [0x55c457]
       /lib64/libpthread.so.0() [0x3983207761]
       /lib64/libc.so.6(clone+0x6d) [0x3982ae14fd]
=== --- ---> Locked Here: chan_sip.c line 23922 (handle_request_do)
=== -------------------------------------------------------------------
===
=== Thread ID: 140322649343760 (autoservice_run      started at [  215] autoservice.c ast_autoservice_start())
=== ---> Waiting for Lock #0 (channel.c): MUTEX 3027 ast_waitfor_nandfds c[x] 0x7f9f2800d9e0 (1)
       /usr/sbin/asterisk(ast_bt_get_addresses+0x1d) [0x4e17a0]
       /usr/sbin/asterisk(__ast_pthread_mutex_lock+0xaf) [0x4da979]
       /usr/sbin/asterisk(__ao2_lock+0x5a) [0x44097c]
       /usr/sbin/asterisk() [0x4e8e35]
       /usr/sbin/asterisk() [0x4ee08e]
       /usr/sbin/asterisk() [0x4ee660]
       /usr/sbin/asterisk() [0x4ee9c9]
       /usr/sbin/asterisk() [0x54b9da]
       /usr/sbin/asterisk() [0x55c457]
       /lib64/libpthread.so.0() [0x3983207761]
       /lib64/libc.so.6(clone+0x6d) [0x3982ae14fd]
=== --- ---> Locked Here: chan_sip.c line 23922 (handle_request_do)
=== -------------------------------------------------------------------
===
=== Thread ID: 140322648835856 (pbx_thread           started at [ 5035] pbx.c ast_pbx_start())
=== ---> Waiting for Lock #0 (channel.c): MUTEX 3027 ast_waitfor_nandfds c[x] 0x7f9f2800d9e0 (1)
       /usr/sbin/asterisk(ast_bt_get_addresses+0x1d) [0x4e17a0]
       /usr/sbin/asterisk(__ast_pthread_mutex_lock+0xaf) [0x4da979]
       /usr/sbin/asterisk(__ao2_lock+0x5a) [0x44097c]
       /usr/sbin/asterisk() [0x4e8e35]
       /usr/sbin/asterisk() [0x4ee08e]
       /usr/sbin/asterisk() [0x4ee660]
       /usr/sbin/asterisk() [0x4ee9c9]
       /usr/sbin/asterisk() [0x54b9da]
       /usr/sbin/asterisk() [0x55c457]
       /lib64/libpthread.so.0() [0x3983207761]
       /lib64/libc.so.6(clone+0x6d) [0x3982ae14fd]
=== --- ---> Locked Here: chan_sip.c line 23922 (handle_request_do)
=== -------------------------------------------------------------------
===
=======================================================================

ephone*CLI>
By: Jonathan Thurman (jthurman) 2010-12-21 13:55:50.000-0600

Are you using Realtime dialplan at all?  Possibly related to 18403.
By: Andrea Cristofanini (hydrolife) 2010-12-22 03:34:30.000-0600

Yes we are using Realtime MYSQL.
By: Kinsey Moore (kmoore) 2012-02-10 11:32:09.480-0600

We're finally whittling down the queue of backlogged issues and this one came up.  If possible, could you retest with Asterisk 1.8.9.2 or 1.8.10 RC?  Many locking issues have been solved in the last year and it's very possible that this issue was solved along with them.  If I don't hear back from you, I'll try to reproduce and move along from there.
By: Kinsey Moore (kmoore) 2012-02-10 16:02:42.558-0600

The best I can reproduce at the moment on 1.8.1 seems to be a failure to properly follow the transfer specified in the REFER which doesn't happen in current code.  A "core show locks" on fresh code would be nice, but until I get that I'll focus on checking the one already provided and seeing if locks got swapped around in those areas.
By: Kinsey Moore (kmoore) 2012-02-13 10:42:15.895-0600

It appears that this was fixed in r301790.  If you problem persists, please reopen this issue.