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

[Asterisk Bug Tracker]

The following issue has been SUBMITTED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16152 
====================================================================== 
Reported By:                AlexMS
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16152
Category:                   Applications/app_mixmonitor
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           SVN 
JIRA:                        
Regression:                 No 
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-10-29 06:07 CDT
====================================================================== 
Summary:                    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'


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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-10-29 06:07 AlexMS         New Issue                                    
2009-10-29 06:07 AlexMS         Asterisk Version          => SVN             
2009-10-29 06:07 AlexMS         Regression                => No              
2009-10-29 06:07 AlexMS         SVN Branch (only for SVN checkouts, not tarball
releases) =>  1.4            
2009-10-29 06:07 AlexMS         SVN Revision (number only!) => 226303          
======================================================================