[asterisk-bugs] [Asterisk 0016152]: [patch] MixMonitor thread doesn't exit until channel is dropped

[Asterisk Bug Tracker]

The following issue requires your FEEDBACK. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16152 
====================================================================== 
Reported By:                AlexMS
Assigned To:                dvossel
====================================================================== 
Project:                    Asterisk
Issue ID:                   16152
Category:                   Applications/app_mixmonitor
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Target Version:             1.4.28
Asterisk Version:           SVN 
JIRA:                       SWP-289 
Regression:                 Yes 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 226303 
Request Review:              
====================================================================== 
Date Submitted:             2009-10-29 06:07 CDT
Last Modified:              2009-11-12 16:52 CST
====================================================================== 
Summary:                    [patch] MixMonitor thread doesn't exit until channel
is dropped
Description: 
Hi,
I've noticed that when I apply MixMonitor/StopMixMonitor on a channel the
thread (mixmonitor_thread) only exits when the channel is dropped. If you
have several long calls being monitored, asterisk eats up a lot of memory -
in my case all of it.

For example, using the following dialplan

exten => 103,1,Answer
exten => 103,n,MixMonitor(myfile)
exten => 103,n,Playback(beep)
exten => 103,n,StopMixMonitor
exten => 103,n,Wait(3)
exten => 103,n,Hangup

and observing the CLI (below) you can see that the message "End MixMonitor
Recording" is always displayed (line 11) after the hang up and not after
the StopMixMonitor (line 6), as it used to be. I say used to be, because I
checked in versions 1.4.17 and 1.4.21.1 and it works fine. 

The problem occurs for sure in version 1.4.26 and trunk (revision
226303).

TRUNK CLI:
(1)    -- Executing [103 at from-internal:1] Answer("SIP/4000-08a713d0", "")
in new stack
(2)    -- Executing [103 at from-internal:2] MixMonitor("SIP/4000-08a713d0",
"myfile") in new stack
(3)    -- Executing [103 at from-internal:3] Playback("SIP/4000-08a713d0",
"beep") in new stack
(4)  == Begin MixMonitor Recording SIP/4000-08a713d0
(5)    -- <SIP/4000-08a713d0> Playing 'beep' (language 'en')
(6)    -- Executing [103 at from-internal:4]
StopMixMonitor("SIP/4000-08a713d0", "") in new stack
(7)  == MixMonitor close filestream
(8)    -- Executing [103 at from-internal:5] Wait("SIP/4000-08a713d0", "3")
in new stack
(9)    -- Executing [103 at from-internal:6] Hangup("SIP/4000-08a713d0", "")
in new stack
(10)  == Spawn extension (from-internal, 103, 6) exited non-zero on
'SIP/4000-08a713d0'
(11)  == End MixMonitor Recording SIP/4000-08a713d0
(12)Really destroying SIP dialog
'MzY2NzI1YzAxZTBhZmFlY2E0NTZhMGMwNDkzMjQ0M2U.' Method: ACK

1.4.17 & 1.4.21.2 CLI:
(1)    -- Executing [103 at from-internal:1] Answer("SIP/4000-081f01a0", "")
in new stack
(2)    -- Executing [103 at from-internal:2] MixMonitor("SIP/4000-081f01a0",
"myfile") in new stack
(3)  == Begin MixMonitor Recording SIP/4000-081f01a0
(4)    -- Executing [103 at from-internal:3] Playback("SIP/4000-081f01a0",
"beep") in new stack
(5)    -- <SIP/4000-081f01a0> Playing 'beep' (language 'en')
(6)    -- Executing [103 at from-internal:4]
StopMixMonitor("SIP/4000-081f01a0", "") in new stack
(7)  == End MixMonitor Recording SIP/4000-081f01a0
(8)    -- Executing [103 at from-internal:5] Wait("SIP/4000-081f01a0", "3")
in new stack
(9)    -- Executing [103 at from-internal:6] Hangup("SIP/4000-081f01a0", "")
in new stack
(10)  == Spawn extension (from-internal, 103, 6) exited non-zero on
'SIP/4000-081f01a0'


====================================================================== 

---------------------------------------------------------------------- 
 (0113754) dvossel (administrator) - 2009-11-12 16:52
 https://issues.asterisk.org/view.php?id=16152#c113754 
---------------------------------------------------------------------- 
I uploaded a patch that should resolve this issue.  Please test it and let
me know.

The filestream is closed during StopMixMonitor allowing for the file to be
accessible to the dialplan immediately, but the thread may close a hair
later than when StopMixMonitor returns.  This means that you might see the
"End Mixmonitor Recording" debug message appear after the next item
executes in the dialplan.  Regardless, the thread now exits properly
instead of waiting for channel destruction, the delay is just the time it
takes for the mixmonitor thread to shutdown after the destruction condition
is received. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-11-12 16:52 dvossel        Note Added: 0113754                          
2009-11-12 16:52 dvossel        Status                   assigned => feedback
======================================================================