[Home]

Summary:ASTERISK-12233: Asterisk crashes sometimes, when using Mixmonitor
Reporter:Eduardo Gomes Santos (edugs15)Labels:
Date Opened:2008-06-19 10:17:14Date Closed:2011-06-07 14:00:35
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Applications/app_mixmonitor
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) output.txt
Description:Hello,

I am using Asterisk 1.4.18.1, Zaptel 1.4.8, Libpri 1.4.3, Addons 1.4.5. It's a Call Center with 30 agents running X-lite.

I am recording all calls by using Mixmonitor.

Since I've started using Mixmonitor, Asterisk crashes and restarts itself, at least twice a day.

Is there a patch to fix this, for Asterisk 1.4.18.1 ?

I don't want to upgrade to 1.4.19 or 1.4.20, at least in this moment, because I am using AgentCallbacklogin.

Could please help me with this issue ?

Thanks.
Comments:By: Mark Michelson (mmichelson) 2008-06-19 10:23:39

Glad to help! What would work best here is if you can upload a backtrace from when a crash occurs. For instructions on how to do this, see doc/backtrace.txt in the Asterisk source directory. I have a feeling, though, that given the intermittent nature of the crashes, that the use of valgrind may be required to track down what's causing the issue. Should that be the case, someone will notify you. The instructions for using valgrind with Asterisk are in doc/valgrind.txt from the Asterisk source directory.

By the way, I'm not sure I understand the connection you made between 1.4.19/1.4.20 and the use of AgentCallbackLogin. Have you found that AgentCallbackLogin is not working properly in those versions?

By: Tilghman Lesher (tilghman) 2008-06-19 10:24:31

For all CRASH bugs, I need you to follow the instructions in doc/backtrace.txt to obtain proper debugging information, so the problem can be found and fixed.

By: Eduardo Gomes Santos (edugs15) 2008-06-19 11:33:23

ok, I'll the instructions.

When it comes to Asterisk 1.4.19/1.4.20 and AgentCallBackLogin, I've tested in 1.4.19.

Agents log in, but can't receive calls from queue.

In fact, I've concluded that AgentCallBackLogin was deprecated in 1.4.19, because I had seen something about it, e did not continue testing it in 1.4.19.


Thanks

By: Tilghman Lesher (tilghman) 2008-06-19 11:59:13

Actually, AgentCallbackLogin was deprecated in 1.4.0.

By: Eduardo Gomes Santos (edugs15) 2008-06-19 12:36:19

Hello, I've just uploaded the file output.txt, with bt, bt full and threads.




Thanks.

By: Mark Michelson (mmichelson) 2008-06-19 16:34:09

I can't be certain of this, but the problem could be the same as what ended up being fixed in issue ASTERISK-11443. What I'm seeing from your backtrace is most likely a corruption of a frame list. In 11999, the problem that eventually was fixed was memory corruption of a frame list. If you can, use the 11999.patch file attached to that issue and see if you still experience the crash.

If the crash still occurs after applying that patch, then what we will need is output from running Asterisk under valgrind. Instructions for how to do this are in doc/valgrind.txt. Thanks!

By: Eduardo Gomes Santos (edugs15) 2008-06-20 08:29:10

Ok,

I will use the patch and see if the crash still occurs.


Thanks.

By: Eduardo Gomes Santos (edugs15) 2008-06-23 08:54:13

Hello,

crash still occurs.

But this bug only occurs when I'm using Mixmonitor in dialplan. If I stop using Mixmonitor, Asterisk runs with no crashes.

Thanks.

By: Mark Michelson (mmichelson) 2008-06-23 09:06:38

If possible, can you run Asterisk under valgrind? Instructions for doing so are in doc/valgrind.txt.

By: Eduardo Gomes Santos (edugs15) 2008-06-23 09:13:41

Hello,

only to be certain that I applied this patch the way it has to be done :

patch -p0 < path/patch
make
make install


There has been no errors at all !


Is it correct ?


Thanks

By: Mark Michelson (mmichelson) 2008-06-23 09:16:45

That is the correct way to apply the patch.

Are you saying that the crashes have stopped now that you have applied the patch? Can this issue be closed?

By: Eduardo Gomes Santos (edugs15) 2008-06-23 09:23:39

No, crash still occurs.

I applied this patch last Friday, at night.

Today, Asterisk has crashed again.

I just wanted to be certain that I had applied this patch the correct way.

Will I have to run Asterisk under Valgrind ?

Thanks

By: Mark Michelson (mmichelson) 2008-06-23 09:36:08

Yes, please run under valgrind if the crash is still occurring. It is the best and quickest way to determine the source of such crashes.

By: Eduardo Gomes Santos (edugs15) 2008-06-23 09:51:39

ok,


I'll follow your instructions.


Thanks.

By: Eduardo Gomes Santos (edugs15) 2008-06-23 11:11:36

Hello,

I forgot to ask some questions. Could you please ask for me ?

- Does Valgrind raise CPU load ? I am concerned about this, because it's a system in production and just can't stop running (that is why I am very concerned about what is hapenning when running Mixmonitor).

- Could my problem be the same as the one fixed in ID 0012047 issue ? At least message erros are the same.

Thanks.

By: Mark Michelson (mmichelson) 2008-06-23 12:31:15

In answer to your questions:

1. Running valgrind does raise CPU usage.

2. It is possible that this is the same issue that was fixed in 12047. Try using the patch from that issue and see if your problem stops.

By: Eduardo Gomes Santos (edugs15) 2008-06-23 17:58:33

Hello,

I'd like to report another issue related to Mixmonitor.

Since I have upgraded from Asterisk 1.4.17 to 1.4.18.1, I am observing latency in recordings.

I get strange files , jittered, slowed and stuttering, no matter wav or gsm format was used.

The problem seems to affect mainly outubound calls.

MixMonitor records one of the legs of the call
with some 10-15 seconds of delay and/or the voice is very quite.

Records one leg of call faster than the other leg. It doesn't align the recording, so one can hear smooth recorded conversation of both called and calling party.

It must be very easy to reproduce this issue, because it always happens.

In Asterisk 1.4.17 this problem doesn't occur.

That is part of my dialplan for outbound calls :

[local-dafra]

exten => _00800.,1,Set(MIXMONITOR_FILENAME=/dev/shm/saidas/${CALLERID(num)}-${CALLERID(dnid)}-${STRFTIME(${EPOCH},,%d%m%Y-%H%M%S)})
exten => _00800.,2,MixMonitor(${MIXMONITOR_FILENAME}.wav,b)
exten => _00800.,3,Dial(Dgv/g1/${EXTEN:1},90,tT)
exten => _00800.,4,Hangup()

exten => _01xx,1,Set(MIXMONITOR_FILENAME=/dev/shm/saidas/${CALLERID(num)}-${CALLERID(dnid)}-${STRFTIME(${EPOCH},,%d%m%Y-%H%M%S)})
exten => _01xx,2,MixMonitor(${MIXMONITOR_FILENAME}.wav,b)
exten => _01xx,3,Dial(Dgv/g1/${EXTEN:1},90,tT)
exten => _01xx,4,Hangup()

exten => _0[2-6]xxxxxxx,1,Set(MIXMONITOR_FILENAME=/dev/shm/saidas/${CALLERID(num)}-${CALLERID(dnid)}-${STRFTIME(${EPOCH},,%d%m%Y-%H%M%S)})
exten => _0[2-6]xxxxxxx,2,MixMonitor(${MIXMONITOR_FILENAME}.wav,b)
exten => _0[2-6]xxxxxxx,3,Dial(Dgv/g1/${EXTEN:1},90,tT)
exten => _0[2-6]xxxxxxx,4,Hangup()


Could you please help with this ?

Thanks.

By: Mark Michelson (mmichelson) 2008-06-24 09:48:56

Someone else or I would be happy to help with that issue, but since it is a different bug, could you please open a new bug report with the information you provided?

Also, have you had any new crashes?

By: Eduardo Gomes Santos (edugs15) 2008-06-24 10:17:43

ok,

I will open a new bug report.

Regarding Asterisk crashes, it's the first day I've been testing the system, after applying latest patches.

I will report the results tomorrow, because crash occurs everyday.

Thanks.

By: Eduardo Gomes Santos (edugs15) 2008-06-26 12:32:00

Hello,

It seems only Asterisk 1.4.21 fix this bug completely.

I had crashes everyday. After upgrading, from 1.4.18.1 to 1.4.21, it's 2 days with no crashes.

Asterisk 1.4.21 fixes recordings out of sync by mixmonitor, as well. In Asterisk 1.4.18 and 1.4.18.1, we observe this bug (recordings out of sync).

In addition, AgentCallbackLogin is working fine in 1.4.21 (it wasn't in 1.4.19). Initially, I was concerned about it, but I had no choice and upgraded to 1.4.21, and everything is ok by now.


Thanks.

By: Tilghman Lesher (tilghman) 2008-06-26 13:36:38

Appears to be already fixed in 1.4.21.