Summary:	ASTERISK-12040: It crashes on the command "reload"
Reporter:	Private Name (falves11)	Labels:
Date Opened:	2008-05-18 13:56:43	Date Closed:	2008-05-21 15:48:12
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_odbc
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) func_odbc_blowup_x1.txt ( 1) func_odbc_blowup.txt ( 2) func_odbc_reload.txt ( 3) rss_and_func_odbc.txt ( 4) sdreen_capture.txt
Description:	I just have to type reload twice and it crashes. And it also crashes at random when the calls are bing made.
Comments:	By: Private Name (falves11) 2008-05-18 14:00:14 [modules] autoload=yes preload =>res_odbc.so preload => func_odbc.conf noload => cdr_odbc.so noload => app_amd.so noload => pbx_dundi.so noload => res_musiconhold.so ;noload => codec_g729.so ;noload => codec_g723.so noload => cdr_custom.so noload => app_followme.so noload => pbx_ael.so noload => chan_skinny.so noload =>  res_smdi.so noload => acl.so noload => chan_iax2.so noload=> chan_mgcp.so [global] ;chan_modem.so=yes By: Digium Subversion (svnbot) 2008-05-19 11:16:47 Repository: asterisk Revision: 117133 U   trunk/res/res_odbc.c ------------------------------------------------------------------------ r117133 | file | 2008-05-19 11:16:46 -0500 (Mon, 19 May 2008) | 4 lines Remove a premature mutex destroy (the destruction callback will end up destroying it) and use a callback to purge remaining classes. (closes issue ASTERISK-12040) Reported by: falves11 ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=117133 By: Digium Subversion (svnbot) 2008-05-19 11:17:59 Repository: asterisk Revision: 117134 _U  branches/1.6.0/ ------------------------------------------------------------------------ r117134 | file | 2008-05-19 11:17:58 -0500 (Mon, 19 May 2008) | 11 lines Blocked revisions 117133 via svnmerge ........ r117133 | file | 2008-05-19 13:22:56 -0300 (Mon, 19 May 2008) | 4 lines Remove a premature mutex destroy (the destruction callback will end up destroying it) and use a callback to purge remaining classes. (closes issue ASTERISK-12040) Reported by: falves11 ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=117134 By: Private Name (falves11) 2008-05-19 17:28:31 I just installed version 117212 and it still blows up. Thsi time I got a weird message about a glibc corruption, on top of the core dump. By: Private Name (falves11) 2008-05-19 17:50:48 Sometimes I see that the amount of ODBC connections goes to over 1000, the limit, althugh in SQL the amount is over 1400, for that IP address. We need to be able to recycle the module res_odbc and make it release its connections, or change the logic so the connections can be reused. By: Digium Subversion (svnbot) 2008-05-20 11:07:40 Repository: asterisk Revision: 117262 U   trunk/res/res_odbc.c ------------------------------------------------------------------------ r117262 | tilghman | 2008-05-20 11:07:38 -0500 (Tue, 20 May 2008) | 4 lines Revert part of previous fix, and heavily comment the logic for object destruction, for future users. (Closes issue ASTERISK-12040) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=117262 By: Digium Subversion (svnbot) 2008-05-20 11:10:47 Repository: asterisk Revision: 117263 _U  branches/1.6.0/ ------------------------------------------------------------------------ r117263 | tilghman | 2008-05-20 11:10:45 -0500 (Tue, 20 May 2008) | 11 lines Blocked revisions 117262 via svnmerge ........ r117262 | tilghman | 2008-05-20 11:13:48 -0500 (Tue, 20 May 2008) | 4 lines Revert part of previous fix, and heavily comment the logic for object destruction, for future users. (Closes issue ASTERISK-12040) ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=117263 By: Digium Subversion (svnbot) 2008-05-20 11:19:20 Repository: asterisk Revision: 117264 U   trunk/CHANGES U   trunk/res/res_odbc.c ------------------------------------------------------------------------ r117264 | tilghman | 2008-05-20 11:19:16 -0500 (Tue, 20 May 2008) | 3 lines Increase limit of unshared connections from 1023 to 4.2 billion. (Related to issue ASTERISK-12040) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=117264 By: Digium Subversion (svnbot) 2008-05-20 11:19:52 Repository: asterisk Revision: 117265 _U  branches/1.6.0/ ------------------------------------------------------------------------ r117265 | tilghman | 2008-05-20 11:19:48 -0500 (Tue, 20 May 2008) | 10 lines Blocked revisions 117264 via svnmerge ........ r117264 | tilghman | 2008-05-20 11:25:16 -0500 (Tue, 20 May 2008) | 3 lines Increase limit of unshared connections from 1023 to 4.2 billion. (Related to issue ASTERISK-12040) ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=117265 By: Digium Subversion (svnbot) 2008-05-20 15:17:14 Repository: asterisk Revision: 117327 _U  team/tilghman/odbc_tx_support/ U   team/tilghman/odbc_tx_support/CHANGES U   team/tilghman/odbc_tx_support/funcs/func_odbc.c U   team/tilghman/odbc_tx_support/main/http.c U   team/tilghman/odbc_tx_support/main/manager.c U   team/tilghman/odbc_tx_support/res/res_odbc.c ------------------------------------------------------------------------ r117327 | tilghman | 2008-05-20 15:17:11 -0500 (Tue, 20 May 2008) | 60 lines Merged revisions 117262,117264,117266,117295,117297 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r117262 | tilghman | 2008-05-20 11:13:48 -0500 (Tue, 20 May 2008) | 4 lines Revert part of previous fix, and heavily comment the logic for object destruction, for future users. (Closes issue ASTERISK-12040) ........ r117264 | tilghman | 2008-05-20 11:25:16 -0500 (Tue, 20 May 2008) | 3 lines Increase limit of unshared connections from 1023 to 4.2 billion. (Related to issue ASTERISK-12040) ........ r117266 | rizzo | 2008-05-20 11:39:39 -0500 (Tue, 20 May 2008) | 5 lines Reverse the check for Cookie: and remove leftover code implementing the same thing. Add an ast_debug() call to help debugging the url matching. ........ r117295 | rizzo | 2008-05-20 12:48:43 -0500 (Tue, 20 May 2008) | 10 lines Document the possible presence of multiple variables with the same name in http queries, which might confuse the manager. Replace calls to ast_uri_decode() with a local function that also replaces '+' with ' ', as this is the normal encoding for spaces in http requests. This allows passing cli commands to the manager through the http interface. ........ r117297 | rizzo | 2008-05-20 13:07:24 -0500 (Tue, 20 May 2008) | 18 lines + Implement a variant of astman_get_header() to return the first or  last match, and possibly skip empty fields.  The function is useful  (and used here) when a form submits multiple 'Action' fields to the  Manager.  This change slightly modifies the current behaviour, but only in the  case the user supplies multiple 'Action: ' lines and the first  ones are empty, so the change is totally harmless. + Fix style on a couple of "if (displayconnects)" statements; + Expand a bit the 'Manager Test' interface, to make it slightly  more user friendly. But also comment that the HTML should not  be embedded in the C source. None of this stuff needs to be applied to 1.4. ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=117327 By: Private Name (falves11) 2008-05-21 10:20:43 I don't know if I should open anew issue, but this is what I observe after using version 117297 in production: the number of connections  grow about 60 a day, but I have just a few calls open on the server. If they got reused, the max amount of connections should not grow to more tha maybe 20 or less, since I don't need to hit the database at the same time. So there is a loose end here somewhere. The pool does not reuse the connections properly or cannnot tell if they are idle. My machine is open for inspection from the developer. I can measure the amount of connections open from the SQL Server side, with a simple SQL statement. By: Joshua C. Colp (jcolp) 2008-05-21 15:48:10 Please open a new issue as the reported issue here has been fixed.