| Summary: | ASTERISK-26867: autochan: Locking in a function ast_autochan_destroy() on destroyed channel (after masquerade). | ||||
| Reporter: | Krzysztof Trempala (kristophert) | Labels: | |||
| Date Opened: | 2017-03-14 02:20:59 | Date Closed: | 2017-03-22 07:57:42 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Applications/app_mixmonitor | ||
| Versions: | 11.25.1 13.14.0 | Frequency of Occurrence | Occasional | ||
| Related Issues: |
| ||||
| Environment: | Ubuntu 12.04 | Attachments: | |||
| Description: | We have a problem with ramdom locking in a function ast_autochan_destroy() on destroyed channel (after masquerade).
This situation is when recording channel (mixmonitor) and stop recording on masquerade event. Then in separate threads are executed functions: - ast_autochan_destroy() in mixmonitor_thread() and - ast_autochan_new_channel() in ast_do_masquerade(). Used variable (not thread safe) "autochan". {code} +------------------------------------------------------+ | MIXMONITOR THREAD | +------------------------------------------------------+ mixmonitor_thread() ... ast_autochan_destroy() ... ast_autochan_channel_lock(autochan); #define ast_autochan_channel_lock(autochan) \ do { \ +----------------------------------------------------+ struct ast_channel *autochan_chan = autochan->chan; \ | CHANNEL THREAD | <-------------------------------------------------+ | ast_channel_lock(autochan_chan); \ | channel_do_masquerade() | if (autochan->chan == autochan_chan) { \ | ... | break; \ | void ast_autochan_new_channel(old_chan, new_chan) | } \ | { | ast_channel_unlock(autochan_chan); \ | ... | } while (1) | autochan->chan = ast_channel_unref(old_chan); | | autochan->chan = ast_channel_ref(new_chan); | | ... | | } | | ... | | destroy(old_chan); | | ... | +----------------------------------------------------+ {code} | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2017-03-14 02:21:00.651-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: Krzysztof Trempala (kristophert) 2017-03-14 02:48:28.037-0500 Issue is related to ASTERISK-25321 By: Joshua C. Colp (jcolp) 2017-03-14 05:28:21.872-0500 Per the Asterisk versions page [1], the maintenance (bug fix) support for the Asterisk branch you are using has ended. For continued maintenance support please move to a supported branch of Asterisk. After testing with a supported branch, if you find this problem has not been resolved, please open a new issue against the latest version of that Asterisk branch. Thanks! [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions By: Friendly Automation (friendly-automation) 2017-03-21 19:48:36.623-0500 Change 5219 merged by zuul: autochan/mixmonitor/chanspy: Fix unsafe channel locking and references. [https://gerrit.asterisk.org/5219|https://gerrit.asterisk.org/5219] By: Friendly Automation (friendly-automation) 2017-03-21 21:53:00.616-0500 Change 5221 merged by zuul: autochan/mixmonitor/chanspy: Fix unsafe channel locking and references. [https://gerrit.asterisk.org/5221|https://gerrit.asterisk.org/5221] By: Friendly Automation (friendly-automation) 2017-03-22 05:11:47.520-0500 Change 5220 merged by Joshua Colp: autochan/mixmonitor/chanspy: Fix unsafe channel locking and references. [https://gerrit.asterisk.org/5220|https://gerrit.asterisk.org/5220] By: Richard Mudgett (rmudgett) 2017-03-22 07:57:42.996-0500 Fixed for v13+ because v11 no longer receives fixes. | ||||