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
Versions:Frequency of
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.


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

Actually, 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


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 */
       if (!mixmonitor->mixmonitor_ds->destruction_ok) {
               ast_cond_wait(&mixmonitor->mixmonitor_ds->destruction_condition, &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.