[Home]

Summary:ASTERISK-08080: app_mixmonitor crashes asterisk
Reporter:Sergey Tamkovich (sergee)Labels:
Date Opened:2006-11-07 11:33:17.000-0600Date Closed:2007-03-05 09:15:30.000-0600
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Applications/app_mixmonitor
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) cli.txt
( 1) cli-debug.txt
Description:When i try to record a call with MixMonitor() i get a segfault right after channels are bridged.

Seems like GSM frame get into spy->read_queue. Segfault happens in ast_frame_slinear_sum(read_frame, write_frame); read_frame type == 2 (gsm) right before segfault.

sip settings:

// caller

[1000]
disallow=all
allow=gsm


//callee

[cisco1]

disallow=all
allow=all



PS: i'm using realtime

****** ADDITIONAL INFORMATION ******

Back trace:

(gdb) bt full
#0  0x0809808e in ast_frame_slinear_sum (f1=0x81f9420, f2=0x81f4db0) at /usr/src/asterisk/include/asterisk/utils.h:192
No locals.
#1  0x0807912f in ast_channel_spy_read_frame (spy=0x81df4b8, samples=160) at channel.c:4365
       result = <value optimized out>
       read_frame = (struct ast_frame *) 0x81f9420
       write_frame = (struct ast_frame *) 0x81f4db0
       need_dup = 0
       stack_read_frame = {frametype = AST_FRAME_VOICE, subclass = 64, datalen = 320, samples = 160, mallocd = 0, mallocd_hdr_len = 0, offset = 0,
 src = 0x0, data = 0xb64971b0, delivery = {tv_sec = 0, tv_usec = 0}, frame_list = {next = 0x0}, has_timing_info = 0, ts = 0, len = 0, seqno = 0}
       stack_write_frame = {frametype = AST_FRAME_VOICE, subclass = 64, datalen = 320, samples = 160, mallocd = 0, mallocd_hdr_len = 0, offset = 0,
 src = 0x0, data = 0xb6497060, delivery = {tv_sec = 0, tv_usec = 0}, frame_list = {next = 0x0}, has_timing_info = 0, ts = 0, len = 0, seqno = 0}
#2  0xb6cee195 in mixmonitor_thread (obj=0x81df4b8) at app_mixmonitor.c:166
       next = (struct ast_frame *) 0x81dc400
       f = (struct ast_frame *) 0x81dc400
#3  0x080eb0eb in dummy_start (data=0x81e1630) at utils.c:545
       __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {136168184, 0, 0, -1236700056, 368799242, -1413698866}, __mask_was_saved = 0}}, __pad = {
   0xb64974a0, 0x0, 0x0, 0x0}}
       __cancel_arg = (void *) 0xb6497ba0
       not_first_call = <value optimized out>
       ret = <value optimized out>
#4  0xb7dff34b in start_thread () from /lib/libpthread.so.0
No symbol table info available.
ASTERISK-1  0xb70db65e in clone () from /lib/libc.so.6
Comments:By: Joshua C. Colp (jcolp) 2006-11-07 17:03:36.000-0600

What is the channel that is being recorded involved in? Is a sound file being played on it? Can you give us the console log?
By: Sergey Tamkovich (sergee) 2006-11-08 01:29:47.000-0600

console log attached.
By: Joshua C. Colp (jcolp) 2006-11-09 21:56:30.000-0600

Can you turn on debug output to console and turn it up? (core set debug 9) this might provide more information about things.
By: Sergey Tamkovich (sergee) 2006-11-14 08:29:56.000-0600

file, sorry, forgot to turn debug on :(
here is my cli with debug.
By: Edward Eastman (whisk) 2006-11-16 07:09:27.000-0600

Are you using the jitterbuffer - it looks a lot like http://bugs.digium.com/view.php?id=8146
By: Fernando Romo (el_pop) 2007-01-16 12:07:40.000-0600

umm, no mather the codec, the same happen to me, here is the bt full:

(gdb) bt full
#0  0x001b0ba1 in kill () from /lib/i686/libc.so.6
No symbol table info available.
#1  0x00536271 in pthread_kill () from /lib/i686/libpthread.so.0
No symbol table info available.
#2  0x005365db in raise () from /lib/i686/libpthread.so.0
No symbol table info available.
#3  0x001b0808 in raise () from /lib/i686/libc.so.6
No symbol table info available.
#4  0x001b1f10 in abort () from /lib/i686/libc.so.6
No symbol table info available.
ASTERISK-1  0x001e477e in __libc_message () from /lib/i686/libc.so.6
No symbol table info available.
ASTERISK-2  0x001eae7f in _int_free () from /lib/i686/libc.so.6
No symbol table info available.
ASTERISK-3  0x001eb226 in free () from /lib/i686/libc.so.6
No symbol table info available.
ASTERISK-4  0x00ccd45f in mixmonitor_thread (obj=0x892a3a8) at app_mixmonitor.c:167
       next = (struct ast_frame *) 0xb76e52a8
       write = Variable "write" is not available.
(gdb) quit

This happen with Asterisk SVN-branch-1.2-r48782 in a production system.


By: Fernando Romo (el_pop) 2007-01-16 12:29:05.000-0600

the problem is in the memory liberation of channel frame. app_mixmonitor.c show:



                       /* it is possible for ast_channel_spy_read_frame() to return a chain
                          of frames if a queue flush was necessary, so process them
                       */
                       for (; f; f = next) {
                               next = f->next;
                               if (write)
                                       ast_writestream(mixmonitor->fs, f);
                               ast_frfree(f);
                       }


The "ast_frfree(f)" call produce the crash, but maybe the function work right but in some cases try to release an empty variable. The crash, in my case, happen 24 to 48 Hours with a 97 agents working and making full recording of the calls. Is preaty random but i notice in the /var/log/asterisk/messges some music on hold events before the crash.
By: jmls (jmls) 2007-01-17 12:47:12.000-0600

this is 1.2, not trunk
By: Serge Vecher (serge-v) 2007-02-26 12:53:58.000-0600

sergee: is this still an issue with 1.2.15 / 1.2 svn?
By: Ronald Chan (loloski) 2007-02-26 16:00:47.000-0600

serge-v: it doesn't segfault at least for me, but i'm having other problem which i i already file it separately, i'm just waiting for the client's permission to activate again mixmonitor.


Ronald
By: Sergey Tamkovich (sergee) 2007-03-05 05:38:49.000-0600

serge-v: just tested - i can't reproduce this crash anymore with current svn-trunk. BTW, it wasn't 1.2 it was SVN-trunk issue.
By: Serge Vecher (serge-v) 2007-03-05 09:15:29.000-0600

spasibo za reportazh :)