[asterisk-bugs] [Asterisk 0010937]: app_mixmonitor crash in ast_channel_spy_read_frame

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10937 
====================================================================== 
Reported By:                ast_rep
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10937
Category:                   Applications/app_mixmonitor
Reproducibility:            random
Severity:                   crash
Priority:                   normal
Status:                     feedback
Asterisk Version:            1.4.11  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             10-10-2007 14:14 CDT
Last Modified:              11-19-2007 09:54 CST
====================================================================== 
Summary:                    app_mixmonitor crash in ast_channel_spy_read_frame
Description: 
We have been experiencing a series of random crashes on our Asterisk 1.4.11

production systems when we use MixMonitor application in our dialplan.
If we coment out the line where MixMonitor is, then the problem desapear.

We are recording calls in queues with the queue mixmonitor and these not
generate prblems. 

gdb's backtrace looks exactly the same for all of the core dumps we
collected.

Versions used:

asterisk 1.4.11 (with tx and rx fax compiled) 
libpri 1.4.1 
zaptel 1.4.5.1 
spandsp 0.0.3
libtiff-3.7.1-6
fedora core 4

We are using Asterisk with about 200 SIP Grandstream phones, we also have
two queues with four SIP members, a dual span E1, and one IAX trunk with
another asterisk 1.4.6

Here is the bt output

http://bugs.digium.com/view.php?id=0  0x0808c2e6 in ast_channel_spy_read_frame
(spy=0x9b3a0b0, samples=160)
at channel.c:4709
http://bugs.digium.com/view.php?id=1  0x0081ce58 in mixmonitor_thread
(obj=0x9b3a0b0) at
app_mixmonitor.c:170
http://bugs.digium.com/view.php?id=2  0x0810b8c9 in dummy_start (data=0x9b12ba0)
at utils.c:775
http://bugs.digium.com/view.php?id=3  0x00bf1b80 in start_thread () from
/lib/libpthread.so.0
http://bugs.digium.com/view.php?id=4  0x00b49dee in clone () from /lib/libc.so.6



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

---------------------------------------------------------------------- 
 ast_rep - 11-19-07 09:54  
---------------------------------------------------------------------- 
I could reproduce the problem on my test environment
asterisk-1.4.6
zaptel-1.4.3
libpri-1.4.0
on fedora core 4

sip.conf (default from make samples, jut added one peer)

[1000]
type=friend
secret=1000
context=test
callerid=fulano <1000>
host=dynamic
nat=yes                        
canreinvite=yes
dtmfmode=info                  
call-limit=2       

extensions.conf

[general]
static=yes
writeprotect=no
clearglobalvars=no

[globals]

[test]

exten => 40,1,Answer
exten => 40,n,Mixmonitor(${UNIQUEID}.wav49)
exten => 40,n,Background(demo-congrats)
exten => 40,n,Hangup

Peer is a BT200. During a call, while hearing demo-congrats I did a hook
flash. Now, if Mixmonitor is commented out, Asterisk will show a warning in
the console, as follows:
 
[Nov 19 12:06:59] WARNING[29591] codec_gsm.c: Invalid GSM data (1)
[Nov 19 12:07:02] VERBOSE[29591] logger.c:   == Spawn extension (test, 40,
2) exited non-zero on 'SIP/1000-084400b0'
[Nov 19 12:07:02] WARNING[29595] codec_gsm.c: Invalid GSM data (1)

Then everything goes well. But if Mixmonitor is running, the warning is
followed by a core dump.

Looks like Asterisk is not acknowledging and taking care of the situation
in ast_channel_spy_read_frame.

I've come to the workaround of disabling hook flash in the BT200 to
prevent this situation. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-19-07 09:54  ast_rep        Note Added: 0073956                          
======================================================================