[asterisk-bugs] [Asterisk 0016737]: large memory leak - ast_rtp_destroy not being call in all circumstances/other associated memory not being freed from chan_sip
Asterisk Bug Tracker
noreply at bugs.digium.com
Wed Apr 6 08:07:17 CDT 2011
The following issue has been CLOSED
======================================================================
https://issues.asterisk.org/view.php?id=16737
======================================================================
Reported By: areyouwireless
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 16737
Category: Channels/chan_sip/General
Reproducibility: always
Severity: major
Priority: normal
Status: closed
Asterisk Version: 1.6.2.1
JIRA: SWP-832
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
Resolution: open
Fixed in Version:
======================================================================
Date Submitted: 2010-01-30 10:32 CST
Last Modified: 2011-04-06 08:07 CDT
======================================================================
Summary: large memory leak - ast_rtp_destroy not being call
in all circumstances/other associated memory not being freed from chan_sip
Description:
I have just downloaded the latest tarball of 1.6.2.1 from the asterisk site
and compiled it under ubuntu. I have a very simple asterisk
installation/configuration consisting of just two 2 extensions (1001 and
1002). Under additional information are the contents of the sip.conf and
extension.conf files. All other configuration files are the default from
the installation. I can successfully place a call between the two
softphones (pjsip v1.5 - www.pjsip.org) without issue when both are
registered.
However if one softphone is not registered, and I place a call to the
other (in this case 1001 is calling 1002), it seems that one of the RTP
sessions is not destroyed leading to a memory leak.
Attached is a log of messages printed out to the console of the problem
occuring. I have compiled asterisk with MALLOC_DEBUG turned on and have
also modified the rtp.c module to output a "warning" level debug message in
the functions ast_rtp_new_with_bindaddr and ast_rtp_destroy:
[Jan 30 09:41:06] WARNING[22266]: rtp.c:2573 ast_rtp_new_with_bindaddr:
rtp_new_with_bindaddr called 0x9067b18
[Jan 30 09:41:06] WARNING[22266]: rtp.c:3140 ast_rtp_destroy: rtp_destory
called 0x9067b18
As you can see from the log message, it also prints out the address of the
ast_rtp structure, thus enabling one to match up the allocation and destroy
operations. I also set sip debug to on so it would also log the sip
traffic.
To induce the problem, all one has to do is:
1) started up asterisk
2) registered extension 1001
3) place a call to 1002 from the softphone 1001
In the asteriskmemoryleak.log:
1) I started up asterisk
2) dumped the base memory allocation summary
3) registered extension 1001
4) dumped memory allocation summary
5) initated a call from extension 1001 to extension 1002
6) since 1002 is not registered, the call failed
7) dumped memory allocation summary
8) initiated another call from extension 1001 to extension 1002
9) since 1002 is still not registered the call failed again
10) dumped memory allocation summary
11) unregistered extension 1001
12) dumped memory allocation summary
If you look at the memory allocation summary, for each call I placed, the
rtp allocation event increases by 12100 bytes. If you look at the Warning
event messages I placed in the rtp module, you will notice that the first
sip/rtp allocation for the incoming call/invite request is never destroyed
when the call fails in this way.
(1st call)
[Jan 30 09:41:06] WARNING[22245]: rtp.c:2573 ast_rtp_new_with_bindaddr:
rtp_new_with_bindaddr called 0x9062fe8
[Jan 30 09:41:06] WARNING[22266]: rtp.c:2573 ast_rtp_new_with_bindaddr:
rtp_new_with_bindaddr called 0x9067b18
[Jan 30 09:41:06] WARNING[22266]: rtp.c:3140 ast_rtp_destroy: rtp_destory
called 0x9067b18
(2nd call)
[Jan 30 09:41:34] WARNING[22245]: rtp.c:2573 ast_rtp_new_with_bindaddr:
rtp_new_with_bindaddr called 0x9068920
[Jan 30 09:41:34] WARNING[22267]: rtp.c:2573 ast_rtp_new_with_bindaddr:
rtp_new_with_bindaddr called 0x906ed90
[Jan 30 09:41:34] WARNING[22267]: rtp.c:3140 ast_rtp_destroy: rtp_destory
called 0x906ed90
Perusing the log, I did a memory dump (memory show summary) you will see
the following information:
12100 bytes in 2 allocations in file 'rtp.c'
.
.
24200 bytes in 4 allocations in file 'rtp.c'
Doing a compare of the memory dumps from after each failed call indicates
that there are other chunks of memory also not release from modules
chan_sip.c
24590 bytes in 17 allocations in file 'chan_sip.c'
28772 bytes in 22 allocations in file 'chan_sip.c'
and a smaller amount in sched.c
10616 bytes in 46 allocations in file 'sched.c'
10636 bytes in 47 allocations in file 'sched.c'
Even after I unregister extension 1001, all of this memory is still
allocated (see the last memory dump).
24200 bytes in 4 allocations in file 'rtp.c'
32211 bytes in 25 allocations in file 'chan_sip.c'
10656 bytes in 48 allocations in file 'sched.c'
I believe that the output of the final memory dump should be close to the
initial memory dump invoked right after startup.
Please let me know if I can be of further assistance.
======================================================================
----------------------------------------------------------------------
(0133438) lmadsen (administrator) - 2011-04-06 08:07
https://issues.asterisk.org/view.php?id=16737#c133438
----------------------------------------------------------------------
Suspended due to lack of response.
Issue History
Date Modified Username Field Change
======================================================================
2011-04-06 08:07 lmadsen Note Added: 0133438
2011-04-06 08:07 lmadsen Status feedback => closed
======================================================================
More information about the asterisk-bugs
mailing list