[Home]

Summary:ASTERISK-10490: app_mixmonitor crash in ast_channel_spy_read_frame
Reporter:ast rep (ast_rep)Labels:
Date Opened:2007-10-10 14:14:22Date Closed:2008-01-16 14:45:01.000-0600
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Applications/app_mixmonitor
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bt_new.txt
( 1) bt-btfull.txt
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

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


Comments:By: ast rep (ast_rep) 2007-10-17 06:41:35

The problem is not present in asterisk 1.4.6


By: 850t (850t) 2007-10-30 20:23:17

We have experienced similar issues on our system Asterisk 1.4.13.

We are using:
asterisk 1.4.13
libpri 1.4.1
zaptel 1.4.5.1
CentOS 5

I have uploaded the stack bt_new.txt.


By: Joshua C. Colp (jcolp) 2007-10-31 13:44:05

Please give the branch located at http://svn.digium.com/svn/asterisk/team/file/audiohooks-1.4 a try and report back. Thanks!
By: ast rep (ast_rep) 2007-11-02 13:26:58

From some research we noticed the problem can be reproduced when both monitoring outbound calls and using Grandstream BT200 phones.

The same operation by using just Eyebeam Softphones will not reproduce the problem.

1.4.6 and 1.4.11 seems to misbehave exactly the same.
By: Tony Plack (plack) 2007-11-15 09:44:35.000-0600

Having the same issue..  Tried audiohooks-1.4.   It too Seg Faults.

Here is the backtrace for the audiohooks-1.4 branch.

(gdb) bt
#0  ast_bridged_channel (chan=0x0) at channel.c:3587
#1  0xb58e56b0 in mixmonitor_thread (obj=0x8245968) at app_mixmonitor.c:169
#2  0x080f87c0 in dummy_start (data=0x8231090) at utils.c:843
#3  0xb7f3d240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#4  0xb702c4ae in clone () from /lib/tls/i686/cmov/libc.so.6
By: ast rep (ast_rep) 2007-11-19 09:54:53.000-0600

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.
By: ast rep (ast_rep) 2007-11-19 13:20:08.000-0600

We noticed two more things. First one, the problem can only be reproduced by using GSM codec. The second, it also can only be reproduced on outgoing calls, not incoming ones.

We tested with EyeBeam latest version but everything worked OK. Looks like a GSM implementation problem in those Grandstream BT200 running firmware 1.1.4.18
By: Tony Plack (plack) 2007-11-20 08:30:20.000-0600

I can reproduce this problem on g729.  I do agree it some seem to be outgoing calls.
By: Joshua C. Colp (jcolp) 2008-01-16 14:45:00.000-0600

Fixed in 1.4 as of revision 98975.