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

Sat Dec 10 20:44:10 CST 2016

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234202#comment-234202 ] 

Asterisk Team commented on ASTERISK-26657:
------------------------------------------

The severity of this issue has been automatically downgraded from "Blocker" to "Major". The "Blocker" severity is reserved for issues which have been determined to block the next release of Asterisk. This severity can only be set by privileged users. If this issue is deemed to block the next release it will be updated accordingly during the triage process.

> 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
>
> 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)