Summary:	ASTERISK-17820: Random crash with RES_ODBC related to SQLSetConnectAttr().
Reporter:	Ian Anderson (seadweller)	Labels:
Date Opened:	2011-05-09 09:00:18	Date Closed:	2011-06-07 14:00:26
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_odbc
Versions:	1.6.2.18	Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) res_odbc_crash_backtrace.txt
Description:	Platform information: CentOS 5.6 Asterisk 1.6.2.18 MySQL 5.5.11 MySQL ODBC Connector 5.1.8 or 3.5.1 unixODBC 2.2.11 (Current CentOS Release) Received a couple random crashes relating to ODBC access.  Thought it was a MySQL Connector issue, as I was initially using 3.5.1, so I upgraded to 5.1.8 and the issue still popped up. I don't believe this bug is related to ASTERISK-1900250 which I posted yesterday.  Connection pooling is not turned on when this happens (the workaround for ASTERISK-1900250)... but because of the other bug, it's hard to test whether it has an effect or not. Not sure if unixODBC 2.2.11 is too old for Asterisk or not?  Though since it seems to be calling SQLSetConnectAttr() in regards to SQL_ATTR_AUTOCOMMIT which is a valid flag in 2.2.11... I don't think this is the issue either. ****** ADDITIONAL INFORMATION ****** I've recompiled a non-optimized Asterisk and running a debug version of the unixODBC libs in hopes I can get a more detailed trace.
Comments:	By: Leif Madsen (lmadsen) 2011-05-09 09:05:34 Honestly, I'd say 95% of crash issues around res_odbc have to do with too old of a unixODBC driver, or using the unixODBC packaged by a distribution. I'd suggest you test with the latest unixODBC driver from unixodbc.org, compiling from source and removing any existing versions from packages. Re-test, and if you're still getting crashes, then please provide a backtrace per https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace Thanks! By: Ian Anderson (seadweller) 2011-05-09 11:14:57 Retesting with a non-optimized Asterisk build.  Once I get a crash and proper backtrace, I'll recompile latest unixODBC and see how it goes. By: Ian Anderson (seadweller) 2011-05-17 09:21:41 Have been testing with a non-optimized Asterisk and the 19250 patch using connection pooling.  Ran over half a million calls through it and no SEGFAULT. Not sure if it would re-appear if pooling was disabled, but at this point... I think this issue can be closed. By: Tilghman Lesher (tilghman) 2011-05-21 14:27:50 Closed by reporter request.