[Home]

Summary:ASTERISK-10072: Memory leak and crash related (probably) to MixMonitor
Reporter:Andrey Solovyev (corruptor)Labels:
Date Opened:2007-08-13 09:14:20Date Closed:2007-10-31 13:55:16
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_mixmonitor
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bt.txt
( 1) manager_eventq.txt
( 2) mem_allocations.txt.gz
( 3) mem_summary.txt
Description:Everytime I enable MixMonitor I expirience strange behavour of asterisk. After about 4-5 days of uptime asterisk begins to consume more and more memory.
Second thing is that asterisk works slower. I can see in CLI how it process every line of the dialplan. For example, I have about 30 lines before Dial cmd and It take about 2-3 before Dial begins. Caller hears silence for those 3 sec.
After restart everything works as it should be for several days.
Today asterisk has crashed and I think this crash is related to the behaviour explained above.
bt is attached.
I relate this to MixMonitor because when I don't use it asterisk works fine with similar dialplan.
If you need any additional info please tell me. Issue is critical.
I can give access via ssh.

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

Server usually has about 7-9 simultanious calls.

Last message in full log is

[13 16:34:24] DEBUG[25656] app_dial.c: Exiting with DIALSTATUS=CANCEL.
[13 16:34:24] DEBUG[25656] app_macro.c: Spawn extension (macro-dialout,s,19) exited non-zero on 'SIP/2605-0ba6a7e0' in macro 'dialout'
[13 16:34:24] DEBUG[25656] pbx.c: Spawn extension (macro-dialout,s,19) exited non-zero on 'SIP/2605-0ba6a7e0'
[13 16:34:24] VERBOSE[25656] logger.c:   == Spawn extension (macro-dialout, s, 19) exited non-zero on 'SIP/2605-0ba6a7e0'
[13 16:34:24] DEBUG[25656] channel.c: Soft-Hanging up channel 'SIP/2605-0ba6a7e0'
[13 16:34:24] VERBOSE[25660] logger.c:   == End MixMonitor Recording SIP/2605-0ba6a7e0
Comments:By: Russell Bryant (russell) 2007-08-19 23:38:07

Build Asterisk with MALLOC_DEBUG enabled.  ("make menuselect", Compiler Flags section, 'x' to save and quit).  Then when Asterisk has consumed a lot of memory, save the output of the "show memory summary" and "show memory allocations" Asterisk CLI commands.  Hopefully that will show us where the memory leak is happening.
By: Andrey Solovyev (corruptor) 2007-09-03 04:56:08

Sorry for delay. First I've upgraded to 1.4.11 and then had to wait for bug to reappear.
I've uploaded output for "show memory summary" and "show memory allocations".
Output shows that problem is related to Manager API not to MixMonitor.
We have an event server which is constantly connected to asterisk and LISTENS to all events. We also have php script which connects to AMI and does Originate command quit often (it's used for our outgoing callcenter).
Something happens and asterisk doesn't clean event queue that's why memory leaks and asterisk works slowly.
Event queue is very huge. I've uploaded only part of event queue because output of "manager show eventq" is very huge.
I have developer who tries to find where the problem is but we need help of course.
Thank you.


By: Volnikov Ivan (ivan) 2007-09-04 07:24:37

It seems like manager API implementation BUG, that happed with a high degree of probability in case that one of AMI authorized client send synchronously action "Action: Originate". In that case the size of the event queue will be increase while "Originate" is not comleted. In this time other AMI client can take short time authorized connection that may be passed an event, but not processed. It leads to that elements of event queue will never not be released any more. I can repeat this situation with a high degree of probability.
By: Joshua C. Colp (jcolp) 2007-10-31 13:55:15

This issue has already been fixed thanks to the fix in 9238.