[Home]

Summary:ASTERISK-09994: Certain realtime IAX calls are causing an malloc error and crash
Reporter:link55 (link55)Labels:
Date Opened:2007-07-31 17:31:30Date Closed:2007-08-23 09:31:25
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Addons/res_config_mysql
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bt_output_iax_refcount.txt
( 1) bt_output_iax_refcount2.txt
( 2) output_better.txt
( 3) output.txt
Description:When using IAX realtime with res_config_mysql, after 1-2 minutes there is a hard crash and core dump.  This has been reproduced in 1.4.9 and SVN-trunk-r77800 with the latest asterisk-addons.  Attached are two GDB traces showing the back trace and what I think might be causing the error - a malformed SQL query.  I Xed out the IPs and usernames.

****** ADDITIONAL INFORMATION ******

(gdb) bt
#0  0x4c5821bb in malloc_consolidate () from /lib/libc.so.6
#1  0x4c5845b3 in _int_malloc () from /lib/libc.so.6
#2  0x4c585d8e in malloc () from /lib/libc.so.6
#3  0x46cdb72d in my_malloc () from /usr/lib/mysql/libmysqlclient.so.15
#4  0x46cde8fa in alloc_root () from /usr/lib/mysql/libmysqlclient.so.15
ASTERISK-1  0x46cffa40 in cli_read_rows () from /usr/lib/mysql/libmysqlclient.so.15
ASTERISK-2  0x46d00471 in unpack_fields () from /usr/lib/mysql/libmysqlclient.so.15
ASTERISK-3  0x46cfebb4 in mysql_real_query () from /usr/lib/mysql/libmysqlclient.so.15
ASTERISK-4  0x448265ea in realtime_mysql (database=0x4086ce78 "asterisk", table=0x4086cd78 "asterisk_iax", ap=0x4086cfa0 "") at res_config_mysql.c:153
ASTERISK-5  0x08090aa6 in ast_load_realtime (family=0x404ef336 "iaxpeers") at config.c:1310
ASTERISK-6 0x404d4773 in realtime_peer (peername=0x4086d4b0 "kirit11", sin=0x0) at chan_iax2.c:2675
ASTERISK-7 0x404d8182 in register_verify (callno=184, sin=0x40870244, ies=0x4086fdd0) at chan_iax2.c:1191
ASTERISK-8 0x404e4649 in socket_process (thread=0x403145f0) at chan_iax2.c:8080
ASTERISK-9 0x404e9b58 in iax2_process_thread (data=0x403145f0) at chan_iax2.c:8404
ASTERISK-10 0x0810082b in dummy_start (data=0x4030a468) at utils.c:557
ASTERISK-11 0x4c6912db in start_thread () from /lib/libpthread.so.0
ASTERISK-12 0x4c5eb12e in clone () from /lib/libc.so.6
(gdb) frame 8
ASTERISK-4  0x448265ea in realtime_mysql (database=0x4086ce78 "asterisk", table=0x4086cd78 "asterisk_iax", ap=0x4086cfa0 "") at res_config_mysql.c:153
153             if (mysql_real_query(&dbread.handle, sql, strlen(sql))) {
(gdb) print sql
$1 = "SELECT * FROM asterisk_iax WHERE name = 'XXX'", '\0' <repeats 211 times>, "??\202D8?\206@\024}iL\v\000\000\000?G?F\023\000\000\000p?\204\t\000@\000\000\000\000\000\000\211G?F\234\005?FX?\206@oH?Fx(\205\tt?\204\t\a\000\000\000\234\005?F??\202Dq@XL??\206@\033`?F??\204\tx(\205\t\a\000\000\000\233?\206@??\206@q@XL\002\000\000\000\000\000\000\000\a\000\000\000q@XL", '\0' <repeats 16 times>, "\020\000\000\000\027?\206"...
(gdb)

...and another one...

(gdb) frame 8
ASTERISK-4  0x429265ea in realtime_mysql (database=0x40c2d458 "asterisk", table=0x40c2d358 "asterisk_iax", ap=0x40c2d588 "") at res_config_mysql.c:153
153             if (mysql_real_query(&dbread.handle, sql, strlen(sql))) {
(gdb) print sql
$1 = "SELECT * FROM asterisk_iax WHERE ipaddr = 'XXX' AND port = '4255'\0001'", '\0' <repeats 40 times>, "s?]L\001\000\000\000\000\000\000\000@??@\235?N@??cL???@", '\0' <repeats 12 times>, "q@XL", '\0' <repeats 20 times>, "\001", '\0' <repeats 283 times>, "\2212iL\000\000\000\000\000\000\000\000?u\000\000\000\000\000\000\000\000\000\000|CiL\000\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\2109T\t"
(gdb) quit
Comments:By: Russell Bryant (russell) 2007-08-16 16:41:44

I have a branch against 1.4 that should fix this.  Please try it out.

http://svn.digium.com/svn/asterisk/team/russell/iax_refcount
By: Jon Creasy (johann8384) 2007-08-17 23:31:17

This is happening with our 1.4.10.1 systems. What can we provide to assist in debugging?
By: Russell Bryant (russell) 2007-08-19 23:34:07

Check out and install the svn branch that I put in my last note.  It should fix the problems reported here.  I plan to merge these changes into 1.4 after they get a bit more testing.
By: Jon Creasy (johann8384) 2007-08-21 11:02:05

I've been running this for about 24 hours. I have an uptime of 24 minutes. I'll check out the logs and see if I have anything interesting for you.
By: Jon Creasy (johann8384) 2007-08-21 11:11:09

root@deon:/var/log/asterisk# grep "Aug 21 " /var/log/asterisk/full | grep -B 4 "Asterisk Event Logger Started"
[Aug 21 06:50:57] DEBUG[2535] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug 21 06:50:57] DEBUG[2535] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_users WHERE host = '71.96.77.217' ORDER BY host
[Aug 21 06:50:57] DEBUG[2535] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug 21 06:50:57] DEBUG[2535] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_users WHERE ipaddr = '71.96.77.217' ORDER BY ipaddr
[Aug 21 06:51:01] VERBOSE[3079] logger.c: Asterisk Event Logger Started /var/log/asterisk/event_log
--
[Aug 21 06:51:04] DEBUG[3088] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug 21 06:51:04] DEBUG[3088] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_users WHERE host = '71.96.77.217' ORDER BY host
[Aug 21 06:51:04] DEBUG[3088] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug 21 06:51:04] DEBUG[3088] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_users WHERE ipaddr = '71.96.77.217' ORDER BY ipaddr
[Aug 21 06:51:08] VERBOSE[3115] logger.c: Asterisk Event Logger Started /var/log/asterisk/event_log
--
[Aug 21 06:51:12] DEBUG[3124] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug 21 06:51:12] DEBUG[3124] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_users WHERE host = '71.96.77.217' ORDER BY host
[Aug 21 06:51:12] DEBUG[3124] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug 21 06:51:12] DEBUG[3124] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_users WHERE ipaddr = '71.96.77.217' ORDER BY ipaddr
[Aug 21 06:51:16] VERBOSE[3151] logger.c: Asterisk Event Logger Started /var/log/asterisk/event_log
--
[Aug 21 07:59:09] DEBUG[3160] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug 21 07:59:09] DEBUG[3160] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_users WHERE host = '71.96.77.217' ORDER BY host
[Aug 21 07:59:09] DEBUG[3160] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug 21 07:59:09] DEBUG[3160] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_users WHERE ipaddr = '71.96.77.217' ORDER BY ipaddr
[Aug 21 07:59:13] VERBOSE[3235] logger.c: Asterisk Event Logger Started /var/log/asterisk/event_log
--
[Aug 21 07:59:16] DEBUG[3244] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug 21 07:59:16] DEBUG[3244] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_users WHERE host = '71.96.77.217' ORDER BY host
[Aug 21 07:59:16] DEBUG[3244] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug 21 07:59:16] DEBUG[3244] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_users WHERE ipaddr = '71.96.77.217' ORDER BY ipaddr
[Aug 21 07:59:20] VERBOSE[3271] logger.c: Asterisk Event Logger Started /var/log/asterisk/event_log
--
[Aug 21 07:59:24] DEBUG[3280] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug 21 07:59:24] DEBUG[3280] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_users WHERE host = '71.96.77.217' ORDER BY host
[Aug 21 07:59:24] DEBUG[3280] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug 21 07:59:24] DEBUG[3280] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_users WHERE ipaddr = '71.96.77.217' ORDER BY ipaddr
[Aug 21 07:59:28] VERBOSE[3307] logger.c: Asterisk Event Logger Started /var/log/asterisk/event_log
--
[Aug 21 07:59:30] DEBUG[3316] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug 21 07:59:30] DEBUG[3316] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_users WHERE host = '71.96.77.217' ORDER BY host
[Aug 21 07:59:30] DEBUG[3316] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug 21 07:59:30] DEBUG[3316] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_users WHERE ipaddr = '71.96.77.217' ORDER BY ipaddr
[Aug 21 07:59:34] VERBOSE[3343] logger.c: Asterisk Event Logger Started /var/log/asterisk/event_log
--
[Aug 21 07:59:53] DEBUG[3352] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug 21 07:59:53] DEBUG[3352] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_users WHERE host = '71.96.77.217' ORDER BY host
[Aug 21 07:59:53] DEBUG[3352] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug 21 07:59:53] DEBUG[3352] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_users WHERE ipaddr = '71.96.77.217' ORDER BY ipaddr
[Aug 21 07:59:57] VERBOSE[3379] logger.c: Asterisk Event Logger Started /var/log/asterisk/event_log
--
[Aug 21 10:54:00] DEBUG[3388] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug 21 10:54:00] DEBUG[3388] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_users WHERE host = '71.96.77.217' ORDER BY host
[Aug 21 10:54:00] DEBUG[3388] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug 21 10:54:00] DEBUG[3388] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_users WHERE ipaddr = '71.96.77.217' ORDER BY ipaddr
[Aug 21 10:54:04] VERBOSE[4482] logger.c: Asterisk Event Logger Started /var/log/asterisk/event_log
--
[Aug 21 10:54:07] DEBUG[4491] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug 21 10:54:07] DEBUG[4491] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_users WHERE host = '71.96.77.217' ORDER BY host
[Aug 21 10:54:07] DEBUG[4491] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug 21 10:54:07] DEBUG[4491] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_users WHERE ipaddr = '71.96.77.217' ORDER BY ipaddr
[Aug 21 10:54:11] VERBOSE[4519] logger.c: Asterisk Event Logger Started /var/log/asterisk/event_log
--
[Aug 21 10:54:15] DEBUG[4528] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug 21 10:54:15] DEBUG[4528] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_users WHERE host = '71.96.77.217' ORDER BY host
[Aug 21 10:54:15] DEBUG[4528] res_config_mysql.c: MySQL RealTime: Everything is fine.
[Aug 21 10:54:15] DEBUG[4528] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_users WHERE ipaddr = '71.96.77.217' ORDER BY ipaddr
[Aug 21 10:54:19] VERBOSE[4556] logger.c: Asterisk Event Logger Started /var/log/asterisk/event_log
root@deon:/var/log/asterisk#
By: Russell Bryant (russell) 2007-08-21 12:02:23

It sounds like you are getting crashes, for sure.  Please build Asterisk with DONT_OPTIMIZE and get a backtrace of the crash using gdb.

gdb /usr/sbin/asterisk core.12345
(gdb) bt
(gdb) bt full
By: Jon Creasy (johann8384) 2007-08-21 18:08:25

Here is the bt info from the latest core file. I used the instructions at:

http://svn.digium.com/svn/asterisk/trunk/doc/backtrace.txt

but it doesn't quite look like what you want. Let me know if it is not.
By: Jon Creasy (johann8384) 2007-08-21 20:17:47

bad news, I crashed again
good news, I got a much better bt :)
By: Jon Creasy (johann8384) 2007-08-21 20:28:15

I know it will be obvious to you when you look at this but I'm trying to learn a little bit as I go along so hopefully I'll be fixing stuff myself before long.

To me the problem looks like it's crashing trying to print to the return value of a vsnprintf to an int res in ast_dynamic_str_thread_build_va.

The message is "Variable 'res' is not available". My C is weak, that is line 1200, line 1194 is "int res;".

#3  0x080fbf87 in ast_dynamic_str_thread_build_va (buf=0xb7e7233c, max_len=8192, ts=0x825cd60, append=0,
   fmt=0x281380 "MySQL RealTime: Database Select Failed (%d): %s\n", ap=0xb7e74664 "S%(") at utils.c:1200
       res = Variable "res" is not available.

/*!
* core handler for dynamic strings.
* This is not meant to be called directly, but rather through the
* various wrapper macros
* ast_str_set(...)
* ast_str_append(...)
* ast_str_set_va(...)
* ast_str_append_va(...)
*/
int __ast_str_helper(struct ast_str **buf, size_t max_len,
int append, const char *fmt, va_list ap)
{
int res, need;
int offset = (append && (*buf)->len) ? (*buf)->used : 0;

if (max_len < 0)
max_len = (*buf)->len; /* don't exceed the allocated space */
/*
* Ask vsnprintf how much space we need. Remember that vsnprintf
* does not count the final '\0' so we must add 1.
*/
res = vsnprintf((*buf)->str + offset, (*buf)->len - offset, fmt, ap);

need = res + offset + 1;
/*
* If there is not enough space and we are below the max length,
* reallocate the buffer and return a message telling to retry.
*/
if (need > (*buf)->len && (max_len == 0 || (*buf)->len < max_len) ) {
if (max_len && max_len < need) /* truncate as needed */
need = max_len;
else if (max_len == 0) /* if unbounded, give more room for next time */
need += 16 + need/4;
if (0) /* debugging */
ast_verbose("extend from %d to %d\n", (int)(*buf)->len, need);
if (ast_str_make_space(buf, need)) {
ast_verbose("failed to extend from %d to %d\n", (int)(*buf)->len, need);
return AST_DYNSTR_BUILD_FAILED;
}
(*buf)->str[offset] = '\0'; /* Truncate the partial write. */

/* va_end() and va_start() must be done before calling
* vsnprintf() again. */
return AST_DYNSTR_BUILD_RETRY;
}
/* update space used, keep in mind the truncation */
(*buf)->used = (res + offset > (*buf)->len) ? (*buf)->len : res + offset;

return res;
}
By: Jon Creasy (johann8384) 2007-08-21 20:38:40

Ok, I have learned how to use gdb a little better now. I was using the core with the wrong asterisk binary.

output.txt is useless.

output_better.txt is a different box with a different crash, please feel free to check that one out, it's 1.4.10.1.

bt_output_iax_refcount.txt is output when I ran two recent crashes against the branch binary.

bt_output_iax_refcount.txt is output when I ran two recent crashes against the branch binary.
By: Digium Subversion (svnbot) 2007-08-22 15:42:43

Repository: asterisk
Revision: 80390

------------------------------------------------------------------------
r80390 | russell | 2007-08-22 15:42:42 -0500 (Wed, 22 Aug 2007) | 3 lines

Don't crash when using realtime in chan_sip without an insecure setting in the database.
(closes issue ASTERISK-9994, reported by link55, fixed by me)

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-08-22 15:45:26

Repository: asterisk
Revision: 80391

------------------------------------------------------------------------
r80391 | russell | 2007-08-22 15:45:26 -0500 (Wed, 22 Aug 2007) | 11 lines

Merged revisions 80390 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r80390 | russell | 2007-08-22 16:00:44 -0500 (Wed, 22 Aug 2007) | 3 lines

Don't crash when using realtime in chan_sip without an insecure setting in the database.
(closes issue ASTERISK-9994, reported by link55, fixed by me)

........

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-08-22 16:43:07

Repository: asterisk
Revision: 80417

------------------------------------------------------------------------
r80417 | file | 2007-08-22 16:43:06 -0500 (Wed, 22 Aug 2007) | 73 lines

Merged revisions 80387-80388,80391,80408 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r80387 | russell | 2007-08-22 17:44:23 -0300 (Wed, 22 Aug 2007) | 42 lines

Merged revisions 80362 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r80362 | russell | 2007-08-22 15:21:36 -0500 (Wed, 22 Aug 2007) | 34 lines

Merge changes from team/russell/iax_refcount.

This set of changes fixes problems with the handling of iax2_user and iax2_peer
objects.  It was very possible for a thread to still hold a reference to one of
these objects while a reload operation tries to delete them.  The fix here is to
ensure that all references to these objects are tracked so that they can't go away
while still in use.

To accomplish this, I used the astobj2 reference counted object model.  This
code has been in one of Luigi Rizzo's branches for a long time and was primarily
developed by one of his students, Marta Carbone.  I wanted to go ahead and bring
this in to 1.4 because there are other problems similar to the ones fixed by these
changes, so we might as well go ahead and use the new astobj if we're going to go
through all of the work necessary to fix the problems.

As a nice side benefit of these changes, peer and user handling got more efficient.
Using astobj2 lets us not hold the container lock for peers or users nearly as long
while iterating.  Also, by changing a define at the top of chan_iax2.c, the objects
will be distributed in a hash table, drastically increasing lookup speed in these
containers, which will have a very big impact on systems that have a large number of
users or peers.

The use of the hash table will be made the default in trunk.  It is not the default
in 1.4 because it changes the behavior slightly.  Previously, since peers and users
were stored in memory in the same order they were specified in the configuration file,
you could influence peer and user matching order based on the order they are specified
in the configuration.  The hash table does not guarantee any order in the container,
so this behavior will be going away.  It just means that you have to be a little
more careful ensuring that peers and users are matched explicitly and not forcing
chan_iax2 to have to guess which user is the right one based on secret, host, and
access list settings, instead of simply using the username.

If you have any questions, feel free to ask on the asterisk-dev list.

........

................
r80388 | russell | 2007-08-22 17:46:16 -0300 (Wed, 22 Aug 2007) | 2 lines

Unsubscribe from MWI events in the peer destructor

................
r80391 | russell | 2007-08-22 18:03:27 -0300 (Wed, 22 Aug 2007) | 11 lines

Merged revisions 80390 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r80390 | russell | 2007-08-22 16:00:44 -0500 (Wed, 22 Aug 2007) | 3 lines

Don't crash when using realtime in chan_sip without an insecure setting in the database.
(closes issue ASTERISK-9994, reported by link55, fixed by me)

........

................
r80408 | russell | 2007-08-22 18:35:08 -0300 (Wed, 22 Aug 2007) | 1 line

allow peers and users to go into a hash table
................

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-08-23 09:31:25

Repository: asterisk
Revision: 80465

------------------------------------------------------------------------
r80465 | bweschke | 2007-08-23 09:31:24 -0500 (Thu, 23 Aug 2007) | 78 lines

Merged revisions 80360,80362,80390,80424,80426 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r80360 | russell | 2007-08-22 15:53:30 -0400 (Wed, 22 Aug 2007) | 5 lines

Juggie in #asterisk-dev was reporting problems where fgets would return
without reading  the whole line when using fastagi.  When this happens,
errno was set to EINTR or EAGAIN.  This patch accounts for the possibility
and lets fgets continue in that case.

........
r80362 | russell | 2007-08-22 16:21:36 -0400 (Wed, 22 Aug 2007) | 34 lines

Merge changes from team/russell/iax_refcount.

This set of changes fixes problems with the handling of iax2_user and iax2_peer
objects.  It was very possible for a thread to still hold a reference to one of
these objects while a reload operation tries to delete them.  The fix here is to
ensure that all references to these objects are tracked so that they can't go away
while still in use.

To accomplish this, I used the astobj2 reference counted object model.  This
code has been in one of Luigi Rizzo's branches for a long time and was primarily
developed by one of his students, Marta Carbone.  I wanted to go ahead and bring
this in to 1.4 because there are other problems similar to the ones fixed by these
changes, so we might as well go ahead and use the new astobj if we're going to go
through all of the work necessary to fix the problems.

As a nice side benefit of these changes, peer and user handling got more efficient.
Using astobj2 lets us not hold the container lock for peers or users nearly as long
while iterating.  Also, by changing a define at the top of chan_iax2.c, the objects
will be distributed in a hash table, drastically increasing lookup speed in these
containers, which will have a very big impact on systems that have a large number of
users or peers.

The use of the hash table will be made the default in trunk.  It is not the default
in 1.4 because it changes the behavior slightly.  Previously, since peers and users
were stored in memory in the same order they were specified in the configuration file,
you could influence peer and user matching order based on the order they are specified
in the configuration.  The hash table does not guarantee any order in the container,
so this behavior will be going away.  It just means that you have to be a little
more careful ensuring that peers and users are matched explicitly and not forcing
chan_iax2 to have to guess which user is the right one based on secret, host, and
access list settings, instead of simply using the username.

If you have any questions, feel free to ask on the asterisk-dev list.

........
r80390 | russell | 2007-08-22 17:00:44 -0400 (Wed, 22 Aug 2007) | 3 lines

Don't crash when using realtime in chan_sip without an insecure setting in the database.
(closes issue ASTERISK-9994, reported by link55, fixed by me)

........
r80424 | russell | 2007-08-22 18:40:27 -0400 (Wed, 22 Aug 2007) | 10 lines

When converting this code to use the list macros, I changed it so objects are
added to the head of a bucket instead of the tail.  However, while looking over
code with mmichelson, we noticed that the algorithm used in ao2_iterator_next
requires that items are added to the tail.  This wouldn't have caused any huge
problem, but it wasn't correct.  It meant that if an object was added to a
container while you were iterating it, and it was added to the same bucket that
the current element is in, then the new object would be returned by
ao2_iterator_next, and any other objects in the bucket would be bypassed in
the traversal.

........
r80426 | russell | 2007-08-22 18:54:03 -0400 (Wed, 22 Aug 2007) | 6 lines

Add some more documentation on iterating ao2 containers.  The documentation
implies that is possible to miss an object or see an object twice while
iterating.  After looking through the code and talking with mmichelson, I have
documented the exact conditions under which this can happen (which are rare and
harmless in most cases).

........

------------------------------------------------------------------------