[Home]

Summary:ASTERISK-16132: StopMixMonitor crashes at the end of the recording, when initiated by the callee.
Reporter:Rommel Raj (rommelraj)Labels:
Date Opened:2010-05-23 05:55:27Date Closed:2011-06-07 14:01:04
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Applications/app_mixmonitor
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) gdb.txt
Description:StopMixMonitor crashes at the end of the recording with a core dump.
This seems to only happen when the callee initiates the recording.
I have tried this many times and it always crashes.
I think it worked with version 1.6.1.1. But not with 1.6.2.6 or 1.6.2.7.


****** STEPS TO REPRODUCE ******

[macro-userrecord]
; starts recording
exten => s,n,GotoIf($["${IsUserRecord}" = "0" | "${IsUserRecord}" = ""]?startuserrec:recuserrunning)

exten => s,n(startuserrec),NoOp
exten => s,n,Set(IsUserRecord=1)
.... I GET SOME DB VARIABLES HERE
....
exten => s,1(allset),Noop()
exten => s,n,Set(MONITOR_FILENAME=${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)})
exten => s,n,Playback(beep)
exten => s,n,MixMonitor(${MONITOR_FILENAME}.WAV, b,/usr/bin/perl /usr/local/sbin/pbx2email.pl "^{MONITOR_FILENAME}.WAV" "^{Dnis}" "^{Cid}" "^{VMEmail}" "^{MyCallType}" "-d")
exten => s,n,MacroExit()

; Stops recording
exten => s,1(recuserrunning),Noop
exten => s,n,Set(IsUserRecord=0)
exten => s,n,StopMixMonitor()
exten => s,n,PlayBack(beep)
exten => s,n(finish),MacroExit()


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

I have a perl script that emails me the recording after it is done.
This works great for caller initiated recordings, but when the call is an incoming call, it crashes.

I trigger the recording with a feature code. *5

features.conf has:
[applicationmap]
userrecord =>*5,self/both,Macro,userrecord
Comments:By: Rommel Raj (rommelraj) 2010-05-23 06:49:41

Few more observations:
1. The recorded file is in the monitor folder. The script does not execute.
2. If your callee hangs up and the DAHDI channel closed, then it does not crash.
It only crashes when the StopMixMonitor is called while the call is still active.
3. Using the standard featuremap for mixmonitor works fine both ways. Seems like the issue is linked with applicationmap.


By: Paul Belanger (pabelanger) 2010-05-23 09:51:27

Thank you for your bug report. In order to move your issue forward, we require a backtrace from the core file produced after the crash. Please see the doc/backtrace.txt file in your Asterisk source directory.

Also, be sure you have DONT_OPTIMIZE enabled in menuselect within the Compiler Flags section, then:

make install

after enabling, reproduce the crash, and then execute the instructions in doc/backtrace.txt.

When complete, attach that file to this issue report. Thanks!
By: Rommel Raj (rommelraj) 2010-05-23 22:44:35

Ok. I uploaded the gdb.txt trace file.

Looks like the frame pointer is null (0xf), within the array frame_list when it is being passed from channel.c (line 3547) to ast_audiohook_write_list
By: Rommel Raj (rommelraj) 2010-05-29 05:38:34

Prossible fix:
I traced the bug with DDD and added the following lines in channel.c and frame.c to fix the issue. I am not sure why the array has the 0xf value. I did not try to figure out how it got placed in the array.

In channel.c: 3546
     for (cur = f; cur; cur = AST_LIST_NEXT(cur, frame_list)) {
           if (cur == (struct ast_frame *)0xf) {   /* RRR - 05/28/2010 */
                   break;                          /* RRR - 05/28/2010 */
           }
           new_frame = ast_audiohook_write_list(chan, chan->audiohooks, AST_AUDIOHOOK_DIRECTION_WRITE, cur);

In frame.c: 396
       if (fr == NULL) {                   /* RRR 05/28/2010 */
           return (struct ast_frame *)0xf; /* RRR 05/28/2010 */
       }


This fix/patch seems to make it work ok. Not sure if it is the right way to do this. But it works for me.
I have a 250 phone installation at my insurance company and I needed to get the call recording working asap. So far Asterisk has been doing fine at our company.
By: Leif Madsen (lmadsen) 2010-06-03 11:35:13

Can you try Asterisk 1.6.2.8? It appears there may have been a fix after 1.6.2.7 that would have resolved this issue.
By: Rommel Raj (rommelraj) 2010-06-03 19:06:23

Ok I will try it tonight.
By: Rommel Raj (rommelraj) 2010-06-04 07:00:40

I just tried it on a stock 1.6.2.8. Looks like it works!
Someone must have fixed it.
I will continue to monitor it.
Thanks.
By: Paul Belanger (pabelanger) 2010-06-08 08:35:55

Closing as reporter stated no more issue.