Summary:ASTERISK-06088: MixMonitor crash?
Reporter:BJ Weschke (bweschke)Labels:
Date Opened:2006-01-15 07:11:41.000-0600Date Closed:2006-02-13 21:39:33.000-0600
Versions:Frequency of
Environment:Attachments:( 0) extensions.conf
( 1) full.1300.gz
Description: Looking at the core file, it looks like the segfault is come from file.c, which I think the only reason it would be in there would be from app_mixmonitor, so that's why I've posted this under app_mixmonitor. I'm not really 100% sure though.


Call flow is for a call to come into queue via Zap (T/E411P in this machine configured for PRI), get answered by an agent (SIP phones), and then in some cases (and this appears to be one of them) the agent dials an 800 # to another center and transfers the original call in from Queue out to this 800 #. From the looks of the log it looks like the crash occurred as two of these bridged Zap calls are being broken down. This definitely doesn't happen everytime. This flow has been in production for over a week doing over 1,000 calls a day and this is the first crash that has occurred.
Comments:By: BJ Weschke (bweschke) 2006-01-15 07:17:29.000-0600

Mantis will not let me upload the gzip'd core file here (just over 2Mb) so it's available at http://www.btwtech.com/core.5610.gz

By: BJ Weschke (bweschke) 2006-01-15 09:55:33.000-0600

I don't think this is the cause of the problem, but shouldn't we be executing post_process AFTER we call ast_closestream on the fs structure? In my case, I'm moving a file away on a file handle that's still open, no?

By: BJ Weschke (bweschke) 2006-01-15 09:57:57.000-0600

(gdb) print post_process
$1 = "/bin/mv -f /home/agent-recordings/18003333474.1137263808.3043.inprogress.wav /home/agent-recordings/completed/18003333474.1137263808.3043.wav", '\0' <repeats 882 times>

The segfault is definitely coming as a result of MixMonitor calling ast_closestream on fs with these two Zap channels that are getting broken down between Zap/2-1 and Zap/3-1.

By: BJ Weschke (bweschke) 2006-02-13 21:39:32.000-0600

The earlier patch from another bug with corruption on MixMonitor seems to have solved this one. System has been running cleanly since that patch was put in place.