[Home]

Summary:ASTERISK-17353: The MixMonitor application fails to execute the "command" upon termination if ExtenSpy is used on the channel
Reporter:John Covert (jcovert)Labels:
Date Opened:2011-02-04 10:39:42.000-0600Date Closed:2011-02-07 12:16:15.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_mixmonitor
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:One of my client's clients noticed this week that if they monitor a call which is being recorded, the recording file is not being processed when the call terminates, and an examination of the log shows no execution of the "command".

I have just received this report and have not yet determined if the recording file is still intact.

I expect to have to find and fix this bug myself this weekend, and will upload a patch when I do so.

****** ADDITIONAL INFORMATION ******

Evidence exists that this problem has gone on unnoticed since before we upgraded to 1.8.

Actually 1.8.1.1, but I can't select it.
Comments:By: Jeremy Kister (jkister) 2011-02-04 12:23:17.000-0600

dupe, 18742.

:)
By: John Covert (jcovert) 2011-02-04 13:45:14.000-0600

sorry
By: Jeremy Kister (jkister) 2011-02-04 17:25:52.000-0600

nothing to be sorry about - i just noticed because i entered the same issue just a few hours before. :)
By: John Covert (jcovert) 2011-02-04 20:06:49.000-0600

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.
By: Leif Madsen (lmadsen) 2011-02-07 12:16:14.000-0600

I'm closing this in favour of the other issue I've marked as a duplicate.