[asterisk-bugs] [JIRA] (ASTERISK-27023) res_rtp_asterisk: Deadlock when TURN session in use

[Michael Walton (JIRA)]

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

Michael Walton edited comment on ASTERISK-27023 at 6/20/17 4:24 PM:
--------------------------------------------------------------------

Patch from duplicate ASTERISK-27058. This patch ensures that the TURN session is passed the shared group lock of the ICE session, removing the possibility of deadlock due to unordered acquisition of multiple locks. Patch is against 13.16.0.


was (Author: mike at farsouthnet.com):
Patch from duplicate ASTERISK-27058. This patch ensures that the TURN session is passed the shared group lock of the ICE session, removing the possibility of deadlock due to unordered acquisition of multiple locks.

> res_rtp_asterisk: Deadlock when TURN session in use
> ---------------------------------------------------
>
>                 Key: ASTERISK-27023
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27023
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 13.13.1
>         Environment: Linux 2.6.32-431.el6.x86_64
>            Reporter: Jatin Jain
>            Assignee: Unassigned
>            Severity: Minor
>         Attachments: gstack-asterisk-pjproject-deadlock.txt, res_rtp_asterisk-turn-deadlock-fix.patch, thread_apply_all_bt.txt
>
>
> Facing deadlock in asterisk while working with pjproject. I am using AMI and the connection gets blocked.
> One of the threads takes a mon_lock in do_monitor and then calls pj_ice_sess_send_data in the pjproject library. This thread then tries to acquire another pj_mutex_lock but doesn't get it and keeps on waiting, keeping the mon_lock. 
> {code:xml}
> #0  0x0000003dc280e264 in __lll_lock_wait () from /lib64/libpthread.so.0
> #1  0x0000003dc2809523 in _L_lock_892 () from /lib64/libpthread.so.0
> #2  0x0000003dc2809407 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #3  0x00007f8f2ee17d44 in pj_mutex_lock () from /usr/lib/libasteriskpj.so
> #4  0x00007f8f2ee1eb72 in pj_lock_acquire () from /usr/lib/libasteriskpj.so
> #5  0x00007f8f2ee1ecd8 in grp_lock_acquire () from /usr/lib/libasteriskpj.so
> #6  0x00007f8f2ee1f21e in pj_grp_lock_acquire () from /usr/lib/libasteriskpj.so
> #7  0x00007f8f2edae862 in pj_ice_sess_send_data () from /usr/lib/libasteriskpj.so
> #8  0x00007f8e9fea1afd in __rtp_sendto.clone.4 () from /usr/lib/asterisk/modules/res_rtp_asterisk.so
> #9  0x00007f8e9fea8f98 in ast_rtcp_write_report () from /usr/lib/asterisk/modules/res_rtp_asterisk.so
> #10 0x00007f8e9fea972d in ast_rtcp_write () from /usr/lib/asterisk/modules/res_rtp_asterisk.so
> #11 0x00000000005c3abe in ast_sched_runq ()
> #12 0x00007f8ebc1ed8df in do_monitor () from /usr/lib/asterisk/modules/chan_sip.so
> #13 0x00000000006043b8 in dummy_start ()
> #14 0x0000003dc28079d1 in start_thread () from /lib64/libpthread.so.0
> #15 0x0000003dc20e8b6d in clone () from /lib64/libc.so.6
> {code}
> So no other thread is able to acquire this monlock which leads to deadlock.
> As mentioned in [this|https://community.asterisk.org/t/help-with-asterisk-deadlock-possible-bug/65439] post, I initially thought its a duplicate of ASTERISK-25275 manifesting in a different way, but I am using pjproject version 2.5.5 which already has the fix mentioned there but the issue still persists. 



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