[asterisk-bugs] [JIRA] (ASTERISK-26657) Chan_sip deadlock with local channel and audiohooks

Sat Dec 10 20:44:10 CST 2016

Ruddy G created ASTERISK-26657:
----------------------------------

             Summary: Chan_sip deadlock with local channel and audiohooks
                 Key: ASTERISK-26657
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26657
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: Channels/chan_sip/General
    Affects Versions: 11.14.2
            Reporter: Ruddy G
            Severity: Blocker

Hi,
I discovered what creates a deadlock in asterisk and prevent any new sip registration to occur.

There are two scenarios. 
Scenario 1: A local channel calls an application that installs audiohooks on it before calling a SIP user. At the end of the call, we have a deadlock.

Scenario 2: A SIP user calls a PBX which dial a Local channel with an announcement. That local channel dials another SIP user. This last user answers the phone and transfers it before the announcement is completed.

Scenario 1:
Create a p.call file wih a local channel

Channel: Local/51400000000 at my-inbound
Application: SayAlpha
Data: 123456789

Inside [my-inbound] context, have the channel create an audiohook and then dial a SIP trunk.
At the end of the call, the PBX SIP module is deadlocked.
No new registration is allowed.
Here are the relevant threads backtraces:

Thread 34 (Thread 0xb54eab40 (LWP 31178)):
#0  0xb77ce428 in __kernel_vsyscall ()
#1  0xb71da9e2 in __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:144
#2  0xb71d6275 in _L_lock_928 () from /lib/i386-linux-gnu/libpthread.so.0
#3  0xb71d60f8 in __GI___pthread_mutex_lock (mutex=0x98b2260) at ../nptl/pthread_mutex_lock.c:114
#4  0xb7704fd4 in pthread_mutex_lock (mutex=0x98b2260) at forward.c:192
#5  0x08135b5f in __ast_pthread_mutex_lock (filename=0xb5a93274 "chan_sip.c", lineno=8973, func=0xb5aabf8f <__PRETTY_FUNCTION__.31584> "sip_pvt_lock_full", mutex_name=0xb5a95208 "chan", t=0x98b2260) at lock.c:273
#6  0x0808bdd6 in __ao2_lock (user_data=0x98b2294, lock_how=AO2_LOCK_REQ_MUTEX, file=0xb5a93274 "chan_sip.c", func=0xb5aabf8f <__PRETTY_FUNCTION__.31584> "sip_pvt_lock_full", line=8973, var=0xb5a95208 "chan") at astobj2.c:195
#7  0xb5a04e69 in sip_pvt_lock_full (pvt=0xb6d0c834) at chan_sip.c:8973
#8  0xb5a660cf in handle_request_do (req=0xb54e9c74, addr=0xb54ea1b8) at chan_sip.c:28521
#9  0xb5a65d9c in sipsock_read (id=0xb6f00518, fd=11, events=1, ignore=0x0) at chan_sip.c:28466
#10 0x08130910 in ast_io_wait (ioc=0x97a4738, howlong=1000) at io.c:292
#11 0xb5a67cfe in do_monitor (data=0x0) at chan_sip.c:29064
#12 0x081c5145 in dummy_start (data=0x97a6268) at utils.c:1192
#13 0xb71d3f70 in start_thread (arg=0xb54eab40) at pthread_create.c:312
#14 0xb76f7bee in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129

Thread 2 (Thread 0xb473fb40 (LWP 1265)):
#0  0xb77ce428 in __kernel_vsyscall ()
#1  0xb71da9e2 in __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:144
#2  0xb71d8677 in pthread_cond_signal@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_signal.S:210
#3  0xb7704d84 in __pthread_cond_signal (cond=0xb6d20324) at forward.c:138
#4  0x08135bc4 in __ast_cond_signal (filename=0x81d5f34 "audiohook.c", lineno=491, func=0x81d61d2 <__PRETTY_FUNCTION__.11233> "ast_audiohook_update_status", cond_name=0x81d5f51 "&audiohook->trigger", cond=0xb6d20324) at lock.c:493
#5  0x0808ffb1 in ast_audiohook_update_status (audiohook=0xb6d20304, status=AST_AUDIOHOOK_STATUS_DONE) at audiohook.c:491
#6  0x08090135 in ast_audiohook_detach_list (audiohook_list=0xb6d2e640) at audiohook.c:534
#7  0x080b4e61 in destroy_hooks (chan=0x98b2294) at channel.c:2744
#8  0x080b5087 in ast_hangup (chan=0x98b2294) at channel.c:2804
#9  0x08175e24 in ast_pbx_run_app (data=0x9800c08) at pbx.c:10585
#10 0x081762fa in ast_pbx_outgoing_app (type=0xb4016418 "Local", cap=0xb6f23500, addr=0xb4016420 "5140000000 at my-inbound", timeout=45000, app=0xb401643c "SayAlpha", appdata=0xb4016448 "123456789", reason=0xb473f2c4, synchronous=2, cid_num=0x826f1a6 <__ast_string_field_empty_buffer+2> "", cid_name=0x826f1a6 <__ast_string_field_empty_buffer+2> "", vars=0x0, account=0x826f1a6 <__ast_string_field_empty_buffer+2> "", locked_channel=0x0) at pbx.c:10645
#11 0xb57526ed in attempt_thread (data=0xb2866690) at pbx_spool.c:376
#12 0x081c5145 in dummy_start (data=0xb6f372c8) at utils.c:1192
#13 0xb71d3f70 in start_thread (arg=0xb473fb40) at pthread_create.c:312
#14 0xb76f7bee in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129

Scenario 2:
Caller A calls from outside and reach context [my-inbound]
Inside such context, we do dial a local context with announcement:

Dial(Local/000 at my-local-context,A(myaudio))

Inside the [my-local-context], simply call SIP user B

[my-local-context]
exten => 000,1,Dial(SIP/userb,30)

So, user B answers the phone. Before his myaudio.gsm announcement is completed, he transfers the call to another location.
Basically, B just transfer his own local channel instead of SIP/userA
A deadlock occurs with the same backtraces.

--
This message was sent by Atlassian JIRA
(v6.2#6252)