[asterisk-bugs] [Asterisk 0017081]: [patch] Memory Leak in app_queue

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17081 
====================================================================== 
Reported By:                wliegel
Assigned To:                mmichelson
====================================================================== 
Project:                    Asterisk
Issue ID:                   17081
Category:                   Applications/app_queue
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     ready for testing
Target Version:             1.6.2.9
Asterisk Version:           1.6.0.26 
JIRA:                       SWP-1136 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-03-23 07:12 CDT
Last Modified:              2010-05-06 15:13 CDT
====================================================================== 
Summary:                    [patch] Memory Leak in app_queue
Description: 
Hello,
on a system with lots of realtime queues I have a problem with very high
memory consumption in app_queue.
According to "memory show summary", there is a high number of allocations
in
/usr/src/asterisk-1.6.0.26/include/asterisk/strings.h:390 (>5.000.000
allocations per Day) as well as high memory consumption in app_queue.c:1449
in only a few allocations (>1GB in 778 allocations).

This issue is simply reproducible by typing "queue show" several times in
the cli and watch the allocation summary.
The more (realtime?)queues are configured the faster grows the memory
consumption after each "queue show" command.
====================================================================== 

---------------------------------------------------------------------- 
 (0121505) mmichelson (administrator) - 2010-05-06 15:13
 https://issues.asterisk.org/view.php?id=17081#c121505 
---------------------------------------------------------------------- 
Okay, I believe I have this figured out, and let's just say it's a bit on
the bizarre side.

First off, this technically isn't a memory leak, but an abuse of a handy
facility in Asterisk. Asterisk has an API for string fields. Essentially,
if a structure has a lot of strings within it, we allocate a single block
of memory to house these strings. In the interest of simplicity, if a
string must be resized to be larger than it previously was, then we just
move the string to the next section of the memory block that is available.
If there is not a space large enough, then we allocate a new block of
memory that is twice the size of the previous block. On the other hand, if
a string is shortened, we simply leave it where it currently is. The API is
simple and is designed for cases where a string will be set once and
changed maybe once or twice during the lifetime of the structure.

There is an issue that occurs if we constantly are resizing the same
string. So let's say we initialize the string with a length of 10. Now,
later, we resize it to size 5. Since the string is now smaller, it can stay
where it is. Now, here's the bad part. If we once again try to set the
string's size to 10, the API sees that the string has a length of 5 and
then moves the string to the next available section in the memory block.
Now, consider that this operation gets repeated often. Eventually, there's
no place to put the 10 byte string, so a new block gets allocated at twice
the original block's size.

Now consider that this happens 2100 times in a row...

At first when I ran your script, I was not seeing the same result you
were. Then I changed all my realtime queues to have their "queue_thankyou"
string set to "beep." Doing this caused me to see the issue. The reason is
that every time "queue show" is used at the CLI, all realtime queues are
loaded. When this happens, we initialize all queue components to their
defaults. So the queue_thankyou option is initialized to "queue-thankyou."
Then, after that, all values specified in the realtime backend are
overridden, so the queue_thankyou sound gets changed to "beep." Now the
next time that "queue show" is run, the queue_thankyou sound is changed to
"queue-thankyou" and then back to "beep" again.

So now that I can reproduce the problem, I just need to actually write a
fix. Likely what I will do is just change queues to not use string fields
since they are not a good fit for queues. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-05-06 15:13 mmichelson     Note Added: 0121505                          
======================================================================