[asterisk-bugs] [JIRA] (ASTERISK-26867) Locking in a function ast_autochan_destroy() on destroyed channel (after masquerade).
Krzysztof Trempala (JIRA)
noreply at issues.asterisk.org
Tue Mar 14 02:21:10 CDT 2017
Krzysztof Trempala created ASTERISK-26867:
---------------------------------------------
Summary: Locking in a function ast_autochan_destroy() on destroyed channel (after masquerade).
Key: ASTERISK-26867
URL: https://issues.asterisk.org/jira/browse/ASTERISK-26867
Project: Asterisk
Issue Type: Bug
Security Level: None
Components: Applications/app_mixmonitor
Affects Versions: 11.25.1
Environment: Ubuntu 12.04
Reporter: Krzysztof Trempala
Severity: Critical
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}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list