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

[Asterisk Bug Tracker]

The following issue has been RESOLVED. 
====================================================================== 
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:                     resolved
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:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-10-29 06:07 CDT
Last Modified:              2009-11-19 15:29 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'


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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-11-19 15:29 svnbot         Status                   assigned => resolved
2009-11-19 15:29 svnbot         Resolution               open => fixed       
======================================================================