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

Michael Walton (JIRA) noreply at issues.asterisk.org
Tue Jun 20 16:25:00 CDT 2017


     [ https://issues.asterisk.org/jira/browse/ASTERISK-27023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Walton updated ASTERISK-27023:
--------------------------------------

    Attachment: res_rtp_asterisk-turn-deadlock-fix.patch

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)



More information about the asterisk-bugs mailing list