| Summary: | ASTERISK-27041: Core/PBX: [patch] Deadlock between dialplan execution and application unregistration | ||
| Reporter: | Frederic LE FOLL (flefoll) | Labels: | |
| Date Opened: | 2017-06-08 04:48:45 | Date Closed: | 2017-06-27 17:26:29 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/PBX |
| Versions: | 13.13.0 | Frequency of Occurrence | Occasional |
| Related Issues: | |||
| Environment: | Gentoo | Attachments: | ( 0) conlock-deadlock-en.txt ( 1) pbx_app.c.patch-conlock-deadlock |
| Description: | 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 | ||
| Comments: | By: Asterisk Team (asteriskteam) 2017-06-08 04:48:46.969-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Frederic LE FOLL (flefoll) 2017-06-08 05:05:16.434-0500 I have attached a patch pbx_app.c.patch-conlock-deadlock. I also try to follow the Patch Contribution Process, but I cannot connect to gerrit.asterisk.org at the moment. I will try again from another location. | ||