[asterisk-bugs] [Asterisk 0014636]: memory leak in "strings.c"

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14636 
====================================================================== 
Reported By:                pj
Assigned To:                lmadsen
====================================================================== 
Project:                    Asterisk
Issue ID:                   14636
Category:                   Core/PBX
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 180373 
Request Review:              
====================================================================== 
Date Submitted:             2009-03-10 05:59 CDT
Last Modified:              2009-05-04 16:16 CDT
====================================================================== 
Summary:                    memory leak in "strings.c"
Description: 
memory allocations for strings.c continuously growing, 
after 4 days uptime and small amout of call processed,
my asterisk eats 120MB of RAM.

mmlog is empty

*CLI> core show calls uptime
0 active calls
320 calls processed
System uptime: 4 days, 15 hours, 32 minutes, 58 seconds


======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0014680 unfreed memory in try_calling
====================================================================== 

---------------------------------------------------------------------- 
 (0104158) wedhorn (reporter) - 2009-05-04 16:16
 http://bugs.digium.com/view.php?id=14636#c104158 
---------------------------------------------------------------------- 
pj, it's quite feasible that skinny is leaking some memory, especially
considering your reset issues. indicate2 shouldn't be causing leaks,
although it may stop a core dump which could allow a memory leak to exist
;)

Looking through your mem usage, it seems weird that you don't have more
skinny sessions. Can you confirm you have 5 lines configured and 5 devices
for configured for skinny. Also, it seems you only actually have one
physical device, although it only shows up occasionally (3608 bytes
allocated in        accept_thread at line  6428 of chan_skinny.c).

It's quite possible various stuff gets orphaned when your skinny device
resets (and you seem to have a lot of those). Not sure I can be of much
help, i've a gut feeling that not all the alloc's are recorded for some
reason (either that or your skinny device spends more time disconnected
than connected). 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-05-04 16:16 wedhorn        Note Added: 0104158                          
======================================================================