[asterisk-bugs] [JIRA] (ASTERISK-27041) Core/PBX: [patch] Deadlock between dialplan execution and application unregistration

Richard Mudgett (JIRA) noreply at issues.asterisk.org
Tue Jun 27 17:26:58 CDT 2017


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

Richard Mudgett closed ASTERISK-27041.
--------------------------------------

    Resolution: Fixed

> Core/PBX: [patch] Deadlock between dialplan execution and application unregistration
> ------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-27041
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27041
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/PBX
>    Affects Versions: 13.13.0
>         Environment: Gentoo
>            Reporter: Frederic LE FOLL
>         Attachments: conlock-deadlock-en.txt, pbx_app.c.patch-conlock-deadlock
>
>
> Not easy to reproduce, but we have noticed deadlocks when unloading a module while dialplan is handling a request.
> This is a variation of deadlocks problems described in Asterisk wiki https://wiki.asterisk.org/wiki/display/AST/Locking+in+Asterisk.
> The deadlock is between :
> 1) Dialplan execution: pbx_extension_helper() first taking conlock, then pbx_findapp() [when called] asking for lock on apps list.
> 2) Application unregistration: ast_unregister_application() first taking lock on apps list, then unreference_cached_app() [when called] asking for conlock.
> Not easy to reproduce, but we had several of these deadlocks. I will attach a file with the analysis of two coredumps that we forced after a deadlock.
> Why unregistering an application while running asterisk? In our case, this is because of a module unload / module load in order to take in account new configuration parameters for a module.
> The problem was detected with Asterisk 13.13 but most probably affects older and newer versions, since this portion of code in main/pbx.c and main/pbx_app.c has not changed very much since Asterisk 13.0 (and possibly older versions).
> As a protection, I suggest to modify ast_unregister_application(), so that it anticipated the need of conlock, before taking the lock on apps list. The side effect is a longer unavailability of conlock when unregistering an application. I will attach a patch file for pbx_app.c



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



More information about the asterisk-bugs mailing list