[Home]

Summary:ASTERISK-18356: chan_sip realtime_peer has several memory leaks
Reporter:Walter Doekes (wdoekes)Labels:
Date Opened:2011-08-27 11:09:51Date Closed:2011-11-01 16:03:15
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Channels/chan_sip/DatabaseSupport
Versions:1.8.7.0 Frequency of
Occurrence		Constant
Related
Issues:
is related toASTERISK-18354 sqlite crash for realtime action if config_table is not set
is related toASTERISK-18355 sqlite realtime_multi_func wrongly assumes commented column exists
is related toASTERISK-17792 Posible memleak in realtime_peer
Environment:Attachments:( 0) issueA18356-chan_sip-realtime_peer-LIST-OF-LEAKS-1.8.x.diff
( 1) issueA18356-reviewboard1-backport-1.6.2.x.patch
Description:An assorted bunch of memory leaks in build_peer in chan_sip.c.

Prerequisites:

{code}
$ for x in /etc/asterisk/*.conf ; do echo ">>> $x <<<" ; echo ; cat $x ; echo ; done
>>> /etc/asterisk/extconfig.conf <<<

[settings]
sipusers => sqlite,unused_for_sqlite,sipfriend
sippeers => sqlite,unused_for_sqlite,sipfriend
sipregs => sqlite,unused_for_sqlite,sipreg

>>> /etc/asterisk/extensions.conf <<<

[default]
exten => 200,1,Answer()
exten => 200,n,Wait(1)
exten => 200,n,Hangup()

>>> /etc/asterisk/modules.conf <<<

[modules]
autoload=no
load=chan_sip.so
load=pbx_config.so
load=res_config_sqlite.so
load=res_rtp_asterisk.so

>>> /etc/asterisk/res_config_sqlite.conf <<<

[general]
dbfile => /etc/asterisk/sqlite.db

>>> /etc/asterisk/sip.conf <<<

[general]
allowguest=no
nat=yes

{code}

{code}
$ sqlite /etc/asterisk/sqlite.db
sqlite> CREATE TABLE sipfriend (
 name varchar(15) NOT NULL,
 secret varchar(63) NOT NULL,
 type varchar(15) NOT NULL,
 host varchar(63) NOT NULL,
 ipaddr varchar(63) NOT NULL,
 port int unsigned default NULL,
 insecure varchar(11) NOT NULL
);
sqlite> CREATE TABLE sipreg (
 name varchar(15) NOT NULL,
 ipaddr varchar(15) NOT NULL,
 port int unsigned NOT NULL,
 defaultuser varchar(15) NOT NULL,
 fullcontact varchar(63) NOT NULL,
 regserver varchar(63) NOT NULL,
 useragent varchar(63) NOT NULL,
 lastms int unsigned NOT NULL,
 regseconds int unsigned NOT NULL
);
{code}

----

Leak #1:

{code}
$ sqlite /etc/asterisk/sqlite.db
sqlite> delete from sipfriend;
sqlite> delete from sipreg;
sqlite> insert into sipreg values (200, '', 0, '', '', '', '', 0, 0);
$ asterisk -c
*CLI> sip show user 200 load
*CLI> memory show summary res_config_sqlite.c
      330 bytes in 4 allocations in function 'add_rt_cfg_entry' of 'res_config_sqlite.c'
*CLI> sip show user 200 load
*CLI> memory show summary res_config_sqlite.c
      660 bytes in 8 allocations in function 'add_rt_cfg_entry' of 'res_config_sqlite.c'
*CLI> sip show user 200 load
*CLI> memory show summary res_config_sqlite.c
      990 bytes in 12 allocations in function 'add_rt_cfg_entry' of 'res_config_sqlite.c'
{code}

In the attached LIST-OF-LEAKS this is when varregs is not freed.

----

Leak #2:

I leave this as an exercise to the reader.

----

Leak #3:

{code}
$ sqlite /etc/asterisk/sqlite.db
sqlite> delete from sipfriend;
sqlite> delete from sipreg;
sqlite> insert into sipfriend values (200, 200, 'peer', '127.0.0.1', '', 12345, '');
sqlite> insert into sipreg values (200, '', 0, '', '', '', '', 0, 0);
*CLI> memory show summary res_config_sqlite.c
(empty-ish)
[do an INVITE from localhost but a different port: realtime_peer gets called with a non-zero ast_sockaddr addr]
*CLI> memory show summary res_config_sqlite.c
      826 bytes in 10 allocations in function 'add_rt_multi_cfg_entry' of 'res_config_sqlite.c'
[do another INVITE]
*CLI> memory show summary res_config_sqlite.c
     1652 bytes in 20 allocations in function 'add_rt_multi_cfg_entry' of 'res_config_sqlite.c'
{code}

This is when peerlist is simply NULL-ified without being freed.

----

See the LIST-OF-LEAKS attached diff for a list of problems.

Leaks #1 and #3 are easy to fix, by adding three (or so) free's.

Leaks #2 could use a varregs_is_allocated and vars_is_allocated boolean, because they're sometimes taken from the peerlist. But that would be very ugly. And the function is already an ugly beast.

I suppose I should open a reviewboard item.

Regards,
Walter Doekes
OSSO B.V.

(I flagged it as regression, as the added sipregs table added in 1.6 caused half of these problems. The situation in 1.4 must therefore be less broken.)
Comments:By: Walter Doekes (wdoekes) 2011-08-27 11:11:07.142-0500

(This is not a fix, only a diff pointing out where the breakage is.)
By: Walter Doekes (wdoekes) 2011-08-27 15:58:22.022-0500

P.S. You might need the SQLite bug fixes from ASTERISK-18354 and ASTERISK-18355 to get the example to work properly.Or you could switch to a different database backend.
By: Walter Doekes (wdoekes) 2011-10-06 02:24:14.871-0500

17792 contains one of the leaks mentioned here.

Most of development has focused on reviewboard r1395.