[asterisk-bugs] [Asterisk 0017101]: Asterisk Crashes With Core Dump When FUNC_ODBC Processes SQL Statements With Errors

Asterisk Bug Tracker noreply at bugs.digium.com
Fri Mar 26 10:55:17 CDT 2010


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17101 
====================================================================== 
Reported By:                David Elliott
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17101
Category:                   Functions/func_odbc
Reproducibility:            always
Severity:                   crash
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.2.6 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-03-26 09:23 CDT
Last Modified:              2010-03-26 10:55 CDT
====================================================================== 
Summary:                    Asterisk Crashes With Core Dump When FUNC_ODBC
Processes SQL Statements With Errors
Description: 
When func_odbc /res_odbc processes SQL with table name, column name or
variables missing it generates a segmentation violation and subsequent core
dump.  

This latest set of issues were generated by Asterisk 1.6.2.6 running on a
fully upgraded Centos 5.4 (2.6.18-164.15.1.el5
https://issues.asterisk.org/view.php?id=1 SMP).  The same issue
occurs across a range of Asterisk versions and Linux distributions.  I am
pretty sure the issue is caused by the way ODBC driver errors are handled
by func_odbc / res_odbc.  

The res_odbc / func_odbc reports a syntax error to the console which is
ignored.  Instead of re-acting to the valid ODBC error,   func_odbc /
res_odbc does a DISCONNECT / CONNECT followed by a re-execution of the same
faulty SQL statement.  The software has assumed that the original error was
caused by a connection time out and seeks to fix the problem by
disconnecting and re-connecting to the database.  Needless to say quite
simple, SQL syntax error will stop Asterisk in its tracks. 

 


====================================================================== 

---------------------------------------------------------------------- 
 (0119935) David Elliott (reporter) - 2010-03-26 10:55
 https://issues.asterisk.org/view.php?id=17101#c119935 
---------------------------------------------------------------------- 
Slightly more informative output from Asterisk

    -- Executing [s at func-odbc-test:1] NoOp("SIP/8018-00000000", "Dial
through Conference Test") in new stack
    -- Executing [s at func-odbc-test:2] Answer("SIP/8018-00000000", "") in
new stack
    -- Executing [s at func-odbc-test:3] Wait("SIP/8018-00000000", "2") in
new stack
    -- Executing [s at func-odbc-test:4] Set("SIP/8018-00000000",
"FO_DELETE()") in new stack
[Mar 26 15:54:22] WARNING[30953]: func_odbc.c:183 generic_execute: SQL
Execute returned an error -1: 42000: [MySQL][ODBC 3.51
Driver][mysqld-5.0.77]You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right syntax
to use near '' at line 1 (186)
[Mar 26 15:54:22] WARNING[30953]: func_odbc.c:191 generic_execute: SQL
Exec Direct failed (-1)![DELETE FROM astsys.tbl_hangup_handler WHERE
hup_rowid = ]
[Mar 26 15:54:22] WARNING[30953]: res_odbc.c:583 ast_odbc_direct_execute:
SQL Exec Direct failed.  Attempting a reconnect...
[Mar 26 15:54:22] NOTICE[30953]: res_odbc.c:1427 odbc_obj_connect:
Connecting astsys
[Mar 26 15:54:22] NOTICE[30953]: res_odbc.c:1455 odbc_obj_connect:
res_odbc: Connected to astsys [astsys]
[Mar 26 15:54:22] WARNING[30953]: func_odbc.c:183 generic_execute: SQL
Execute returned an error -1: 42000: [MySQL][ODBC 3.51
Driver][mysqld-5.0.77]You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right syntax
to use near '' at line 1 (186)
[Mar 26 15:54:22] WARNING[30953]: func_odbc.c:191 generic_execute: SQL
Exec Direct failed (-1)![DELETE FROM astsys.tbl_hangup_handler WHERE
hup_rowid = ]
[Mar 26 15:54:22] WARNING[30953]: res_odbc.c:583 ast_odbc_direct_execute:
SQL Exec Direct failed.  Attempting a reconnect...
[Mar 26 15:54:22] NOTICE[30953]: res_odbc.c:1427 odbc_obj_connect:
Connecting astsys
[Mar 26 15:54:22] NOTICE[30953]: res_odbc.c:1455 odbc_obj_connect:
res_odbc: Connected to astsys [astsys]
[Mar 26 15:54:22] ERROR[30953]: astobj2.c:279 __ao2_ref: refcount -1 on
object 0x4047490
[Mar 26 15:54:22] ERROR[30953]: astobj2.c:110 INTERNAL_OBJ: user_data is
NULL
WARNING: Freeing unused memory at 0x4047468, in __ao2_ref of astobj2.c,
line 295
[Mar 26 15:54:22] ERROR[30953]: astobj2.c:279 __ao2_ref: refcount -2 on
object 0x4047490
[Mar 26 15:54:22] ERROR[30953]: astobj2.c:110 INTERNAL_OBJ: user_data is
NULL
WARNING: Freeing unused memory at 0x4047468, in __ao2_ref of astobj2.c,
line 295
WARNING: Freeing unused memory at 0x4047468, in __ao2_ref of astobj2.c,
line 295
[Mar 26 15:54:22] ERROR[30953]: astobj2.c:279 __ao2_ref: refcount -3 on
object 0x4047490
[Mar 26 15:54:22] ERROR[30953]: astobj2.c:110 INTERNAL_OBJ: user_data is
NULL
WARNING: Freeing unused memory at 0x4047468, in __ao2_ref of astobj2.c,
line 295
[Mar 26 15:54:22] ERROR[30953]: astobj2.c:279 __ao2_ref: refcount -4 on
object 0x4047490
[Mar 26 15:54:22] ERROR[30953]: astobj2.c:110 INTERNAL_OBJ: user_data is
NULL
    -- Executing [s at func-odbc-test:5] Hangup("SIP/8018-00000000", "") in
new stack
  == Spawn extension (func-odbc-test, s, 5) exited non-zero on
'SIP/8018-00000000' 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-03-26 10:55 David Elliott  Note Added: 0119935                          
======================================================================




More information about the asterisk-bugs mailing list