[asterisk-bugs] [Asterisk 0011999]: memory leak

noreply at bugs.digium.com noreply at bugs.digium.com
Wed Mar 5 10:44:51 CST 2008


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11999 
====================================================================== 
Reported By:                destiny6628
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11999
Category:                   Core-General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.18 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             02-15-2008 01:20 CST
Last Modified:              03-05-2008 10:44 CST
====================================================================== 
Summary:                    memory leak
Description: 
hi we are using asterisk 1.4.18 , zaptel-1.4.8 and libpri 1.4.3 with 4 e1
card on ibm x3200 server and 90 active calls running on asterisk cli and
after some hours of dialing , swap memory starts getting used and asterisk
gives core dump .

Asterisk is running with safe_asterisk.

vmstat ouput is as follows 

[root at localhost cron]# vmstat
procs -----------memory---------- ---swap-- -----io---- --system--
-----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id
wa st
 1  0    568  57308  44708 1848488    0    0    10   119 1293  509  2  2
95  0  0

Free -m is as follows 

[root at localhost cron]# free -m
             total       used       free     shared    buffers     cached
Mem:          2025       1974         51          0         43       1806
-/+ buffers/cache:        124       1901
Swap:         1983          0       1983


OPERATING SYSTEM is centos 5 and kernel version is [root at localhost cron]#
uname -a
Linux localhost.localdomain 2.6.18-8.el5 http://bugs.digium.com/view.php?id=1
SMP Thu Mar 15 19:57:35 EDT
2007 i686 i686 i386 GNU/Linux

Cannot do valgrind test as it put heavy load on the server and its a
production server .

RAM On the server is 2GB .

Only Asterisk application is running on that .



====================================================================== 

---------------------------------------------------------------------- 
 putnopvut - 03-05-08 10:44  
---------------------------------------------------------------------- 
I spent a few hours this morning attempting to reproduce this problem by
scripting some calls which used Local channels. Unfortunately, no matter
what I tried I could not get a crash to occur, and running with valgrind
did not show any memory corruption problems.

So it looks like there's some specific set of conditions occurring on your
system that is causing this to happen. I'm going to need some information
from you. First of all, if possible, can you describe how it is that you're
using Local channels on your system? The best way to do this would be to
upload the part(s) of your dialplan that use Local channels. Also, one
thing that I have not yet seen is any sort of console output prior to a
crash. If you could turn up the debug level and verbosity level and upload
the lines that print prior to a crash, that may be useful too. The most
helpful thing you could do, if at all possible, would be to run valgrind on
the system since it seems clear that this is an issue of memory
corruption.

Thanks for your patience on this one. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-05-08 10:44  putnopvut      Note Added: 0083451                          
======================================================================




More information about the asterisk-bugs mailing list