[asterisk-bugs] [JIRA] (ASTERISK-25645) res_rtp_asterisk: Lock inversion

[Stian Halseth (JIRA)]

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

Stian Halseth edited comment on ASTERISK-25645 at 9/16/16 3:27 AM:
-------------------------------------------------------------------

I will provide some additional info about this issue as we currently depend on the reverted patch from ASTERISK-25614.

Because the patch from ASTERISK-25614 has been was reverted , this problem is still present in current Asterisk 13.11.2, downloaded and compiled from asterisk.org today.

I would really like someone to look into this and verify whether this patch will cause locking issues with current version of pjproject on current versions of Asterisk 13.

If not, I believe this patch should be reintroduced, at least provide some documentation about the issue, and compatibility requirements for pjproject versions.

When using the latest version of Chrome , 53.0.2785.113 (64-bit), we're experiencing the delay of audio on incoming calls to WebRTC users without this patch.

Happens about 1 in 3, perhaps 1 in 5 times when receiving incoming calls with WebRTC. Issue not present on outgoing calls.
It's a big enough deal braker that we cannot use current 13 LTS og 13 certified in production without manual patching.
I'm not providing too much detail on the problem itself, as it's seems like it's a known issue.

Same issue in current Asterisk 13 certified.

We have fixed this by manually applying the patch https://code.asterisk.org/code/rdiff/asterisk?csid=965a0eee46d24321f74c244e23c5a5f45e67e12b&u&N

We will be conducting extensive testing on Asterisk 13.11.2, with the patch applied. 

Hopefully we can determine that it's safe to install this in production, but we would really appreciate some input from someone with extensive knowledge of the impatch of the patch, and the potensial locking issue.



was (Author: halseth):
I will provide some additional info about this issue as we currently depend on the reverted patch from ASTERISK-25614.

Because the patch from ASTERISK-25614 has been was reverted , this problem is still present in current Asterisk 13.11.2, downloaded and compiled from asterisk.org today.

I would really like someone to look into this and verify whether this patch will cause locking issues with current version of pjproject on current versions of Asterisk 13.

If not, I believe this patch should be reintroduced, at least provide some documentation about the issue, and compatibility requirements for pjproject versions.

When using the latest version of Chrome , 53.0.2785.113 (64-bit), we're experiencing the delay of audio on incoming calls to WebRTC users without this patch.

Happens about 1 in 3, perhaps 1 i 5 times when receiving incoming calls with WebRTC. Issue not present on outgoing calls.
It's a big enough deal braker that we cannot use current 13 LTS og 13 certified in production without manual patching.
I'm not providing too much detail on the problem itself, as it's seems like it's a known issue.

Same issue in current Asterisk 13 certified.

We have fixed this by manually applying the patch https://code.asterisk.org/code/rdiff/asterisk?csid=965a0eee46d24321f74c244e23c5a5f45e67e12b&u&N

We will be conducting extensive testing on Asterisk 13.11.2, with the patch applied. 

Hopefully we can determine that it's safe to install this in production, but we would really appreciate some input from someone with extensive knowledge of the impatch of the patch, and the potensial locking issue.


> res_rtp_asterisk: Lock inversion
> --------------------------------
>
>                 Key: ASTERISK-25645
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25645
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>            Reporter: Steve Davies
>         Attachments: deadlocked_threads.txt, experimental_anti_deadlock, unlock_ice_before_callback
>
>
> Reported by Steve Davies on asterisk-dev:
> commit 5e6b1476a087407a052f007d326c504cfeefebe7
> ASTERISK-25614
> 2 code paths which approximate the following will cause a lock-inversion deadlock:
> approximate call orders are:
> a)
> pj_timer_heap_poll (PJ_LOCK)
> ast_rtp_on_ice_complete
> ast_rtp_instance_set_remote_address
> remote_address_set
> ast_rtp_remote_address_set
> (DTLS_LOCK)
> ...
> b)
> ast_pbx...
> app_dial
> bridge...
> read
> rtp_read
> ...
> __rtp_recvfrom
> (DTLS_LOCK)
> dtls_srtp_check_pending
> __rtp_sendto
> pj_ice_sess_send_data
> (PJ_LOCK)



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