[asterisk-bugs] [JIRA] (ASTERISK-25740) Asterisk aborts after receiving a MySQL syntax error for adaptive_odbc CDR logging

[Chris Syria (JIRA)]

Chris Syria created ASTERISK-25740:
--------------------------------------

             Summary: Asterisk aborts after receiving a MySQL syntax error for adaptive_odbc CDR logging
                 Key: ASTERISK-25740
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25740
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: CDR/cdr_adaptive_odbc
    Affects Versions: 13.6.0
         Environment: Asterisk is running on CentOS 7.2 64-bit
The database server is running on another CentOS 7.2 box. MariaDB Server version: 5.5.44-MariaDB
            Reporter: Chris Syria


On my 13.6.0 production box, we are seeing the Asterisk process crash and get restarted by safe_asterisk every few days. These crashes occur only at the end of calls, and appear to be related to adaptive_odbc logging for CDR. 

In my /var/log/messages:
{code} HOSTNAME asterisk: /usr/sbin//safe_asterisk: line 164:  8661 Aborted                 (core dumped) nice -n $PRIORITY "${ASTSBINDIR}/asterisk" -f ${CLIARGS} ${ASTARGS} > /dev/${TTY} 2>&1 < /dev/${TTY}
{code}

This is the last log I see before it goes down:
{code}
WARNING[9159] res_odbc.c: SetConnectAttr (Txn isolation) returned an error: HY000: [MySQL][ODBC 5.2(w) Driver]You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '7' at line 1
WARNING[9159] res_odbc.c: SQL Execute returned an error -1: 08S01: [MySQL][ODBC 5.2(w) Driver][mysqld-5.5.44-MariaDB]MySQL server has gone away (76)
WARNING[9159] res_odbc.c: SQL Execute error -1! Verifying connection to asterisk-connector [asterisk-connector]...
WARNING[9159] res_odbc.c: Connection is down attempting to reconnect...
{code}

I suspect this is related to the ODBC logging because I see this in the backtrace:
{code}
#0  0x00007fa724d665f7 in raise () from /lib64/libc.so.6
#1  0x00007fa724d67ce8 in abort () from /lib64/libc.so.6
#2  0x00007fa724d5f566 in __assert_fail_base () from /lib64/libc.so.6
#3  0x00007fa724d5f612 in __assert_fail () from /lib64/libc.so.6
#4  0x00007fa6e26ff43a in desc_free_paramdata () from /usr/lib64/libmyodbc5.so
#5  0x00007fa6e2704292 in my_SQLFreeStmtExtended () from /usr/lib64/libmyodbc5.so
#6  0x00007fa6e26fc4e5 in SQLDisconnect () from /usr/lib64/libmyodbc5.so
#7  0x00007fa7129ad46a in SQLDisconnect () from /lib64/libodbc.so.2
#8  0x00007fa712c0ae8b in odbc_obj_disconnect (obj=0x1f678f8) at res_odbc.c:1489
#9  0x00007fa712c07ef1 in ast_odbc_sanity_check (obj=0x1f678f8) at res_odbc.c:766
#10 0x00007fa712c07a04 in ast_odbc_prepare_and_execute (obj=0x1f678f8, prepare_cb=0x7fa6cab80c12 <generic_prepare>, data=0x7fa6dc032c68) at res_odbc.c:670
#11 0x00007fa6cab83682 in odbc_log (cdr=0x7fa6dc0603f0) at cdr_adaptive_odbc.c:742
#12 0x000000000049e386 in post_cdr (cdr=0x7fa6dc0603f0) at cdr.c:3271
#13 0x000000000049fc92 in cdr_detach (cdr=0x7fa6dc0603f0) at cdr.c:3568
#14 0x0000000000497270 in cdr_object_dispatch (cdr=0x7fa6dc0525b8) at cdr.c:1199
#15 0x000000000049a808 in handle_channel_cache_message (data=0x0, sub=0x9aee28, message=0x7fa71803b418) at cdr.c:2129
#16 0x00000000005ccf6c in router_dispatch (data=0x9b0068, sub=0x9aee28, message=0x7fa71803b418) at stasis_message_router.c:201
#17 0x00000000005bc3c5 in subscription_invoke (sub=0x9aee28, message=0x7fa71803b418) at stasis.c:433
#18 0x00000000005bcf01 in dispatch_exec_async (local=0x7fa722d8ac90) at stasis.c:695
#19 0x00000000005d72f3 in ast_taskprocessor_execute (tps=0x9aed38) at taskprocessor.c:776
#20 0x00000000005d5b42 in default_tps_processing_function (data=0x9b03b8) at taskprocessor.c:184
#21 0x00000000005ec2e1 in dummy_start (data=0x9aeb90) at utils.c:1237
#22 0x00007fa725a82dc5 in start_thread () from /lib64/libpthread.so.0
#23 0x00007fa724e2721d in clone () from /lib64/libc.so.6
{code}

I can not see any consistent pattern in the calls that cause this syntax error, nor can I reproduce it on demand. It seems to happen about every 5 days on average. 

I realize that 13.6.0 has been superseded, but I haven't had the chance to schedule an outage window to upgrade to 13.7.0. I did search on some relevant terms in the tracker and didn't see a similar bug being filed. 

 (Also... my apologies to the community if this bug is inappropriate - I tried to follow the steps listed on the issue guidelines, but this is my first submission here). 



--
This message was sent by Atlassian JIRA
(v6.2#6252)