[asterisk-bugs] [Asterisk 0018742]: MIXMON_ARGS not processed when call being monitored via chanspy

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18742 
====================================================================== 
Reported By:                jkister
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18742
Category:                   Applications/app_mixmonitor
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.8.2.3 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2011-02-03 11:02 CST
Last Modified:              2011-02-04 20:56 CST
====================================================================== 
Summary:                    MIXMON_ARGS not processed when call being monitored
via chanspy
Description: 
x146 is talking to an outside line
x143 uses extenspy to listen on x146

x146 hangs up the call to outside line (while x143 is still monitoring)

${MIXMON_ARGS} is not honored.
====================================================================== 

---------------------------------------------------------------------- 
 (0131522) jcovert (reporter) - 2011-02-04 20:56
 https://issues.asterisk.org/view.php?id=18742#c131522 
---------------------------------------------------------------------- 
This is a deadlock of some sort

When there is an ExtenSpy on top of a recording (something that is VERY
important for my client to allow) we get stuck:

        /* Datastore cleanup. close the filestream and wait for ds
destruction */
        ast_mutex_lock(&mixmonitor->mixmonitor_ds->lock);
        mixmonitor_ds_close_fs(mixmonitor->mixmonitor_ds);
        if (!mixmonitor->mixmonitor_ds->destruction_ok) {
               
ast_cond_wait(&mixmonitor->mixmonitor_ds->destruction_condition,
&mixmonitor->mixmonitor_ds->lock);
        }
        ast_mutex_unlock(&mixmonitor->mixmonitor_ds->lock);

destruction_ok is false; we go into ast_cond_wait and never return

This would also explain one of my client's memory leaks on their main
production system.

The thread and all of its storage remain active forever. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-02-04 20:56 jcovert        Note Added: 0131522                          
======================================================================