Summary:	ASTERISK-16828: Segfault related to realtime peers and the astDB
Reporter:	Sébastien Couture (sysreq)	Labels:
Date Opened:	2010-10-18 20:59:22	Date Closed:	2011-07-27 13:05:04
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_odbc
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) backtrace.txt
Description:	I'm just formulating an hypothesis here (from the backtrace), but the problem seems to be related to realtime peers cached into astDB, then used upon restart until the user registers again and a new realtime query is executed to populate the peer's information. sip.conf: rtcachefriends=yes rtsavesysname=yes rtupdate=yes rtautoclear=no ignoreregexpire=yes modules.conf: preload => res_odbc.so preload => res_config_odbc.so ****** ADDITIONAL INFORMATION ****** As soon as we erased the astDB, the segfaults stopped.
Comments:	By: Stefan Schmidt (schmidts) 2010-10-19 04:21:04 when does this segfault happens? it looks like in your backtrace there are many odbc connection opened so maybe the problem is a connection limit and not directly a asterisk problem. this would descripe why clearing/deleting the astdb solves this problem, cause on startup every peer will be checked which is stored in astdb and this could cause too many open odbc connections. By: Leif Madsen (lmadsen) 2010-10-29 08:35:42 Thanks for the backtrace. Someone will take a look at this as time and resources allow. By: Sébastien Couture (sysreq) 2010-10-29 13:21:24 I'm pretty sure it actually had to do with a peer entry with an empty 'name' field in my Realtime 'sipusers' SQL table. Oftentimes, Asterisk will look for an entry with an empty 'name' field (ie. when it receives a UDP packet with no SIP headers and tries to find out the associated peer).. given that I had such an entry in my 'sipusers' table, it brought it up and loaded it in memory as a peer entry with no name, IP address, port, etc. My guess is that Asterisk then tried to poke the peer ('qualify=yes' by default in my SQL table) and choked on the fact that it had no name or other information. By: Russell Bryant (russell) 2011-07-27 13:04:59.092-0500 Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!