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

Thu Feb 4 17:55:32 CST 2016

     [ https://issues.asterisk.org/jira/browse/ASTERISK-25740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton updated ASTERISK-25740:
------------------------------------

    Assignee: Chris Syria
      Status: Waiting for Feedback  (was: Triage)

bq.  I tried to follow the steps listed on the issue guidelines

Thanks! That is actually pretty rare around here (for any bug tracker really). We absolutely appreciate it.

Looks like you have provided almost everything we could ask for.

However a couple more things:

 * Provide a debug log captured right before the crash. (a few minutes of logging or the last 10000 lines is fine) Follow these instructions: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
 * Provide all of your CDR and ODBC configuration (don't forget to sanitize)
 * Attach everything as .txt so it is easily accessible from our browsers.

Thanks again!

> 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
>            Assignee: Chris Syria
>         Attachments: backtrace_201602021206.txt
>
>
> 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)