[asterisk-bugs] [JIRA] (ASTERISK-21786) Segfault in MyODBC MySQL connector during reconnect attempt when connection is lost

Matt Jordan (JIRA) noreply at issues.asterisk.org
Tue May 21 08:55:01 CDT 2013


    [ https://issues.asterisk.org/jira/browse/ASTERISK-21786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=206660#comment-206660 ] 

Matt Jordan commented on ASTERISK-21786:
----------------------------------------

This crash is occurring during a reconnect attempt when the connection to the MySQL database is lost. The backtrace shows the diagnostic message received from the underlying library when this occurs:

{noformat}
        diagnostic = "[MySQL][ODBC 5.1 Driver][mysqld-5.5.30-1.1]MySQL server has gone away\000\000\000AcX\000\000\000\000\000\225��N�\177\000\000\227��N�\177\000\000\v\000\000\000�\002\000\000\064��N�\177\000\000(\000\000\000\060\000\000\000��\027G�\177\000\000\000�\027G�\177\000\000pe!l�\177\000\000\030�\201l�\177\000\000�\003\000\000\000\000\000\000j�\210l�\177\000\000��\211l�\177\000\000\000\000\000\000\000\000\000\000��\211l�\177\000\000\030\000\000\000\060\000\062\000"...
{noformat}

When the underlying connection is broken, Asterisk attempts a reconnect. If the connection is not up, it disposes of the old connection by calling SQLDisconnect on the existing connection object. This is the correct action to take: while the previous execution of a statement failed, that doesn't imply that the underlying connection object has been properly disposed of.

Unfortunately, this is where the crash occurs.

It appears as if this is a bug in the MySQL ODBC connector. It should not be crashing during a SQLDisconnect after execution of a SQL statement has failed. You should report this but to the MySQL ODBC project here:

http://bugs.mysql.com/
                
> Segfault in MyODBC MySQL connector during reconnect attempt when connection is lost
> -----------------------------------------------------------------------------------
>
>                 Key: ASTERISK-21786
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21786
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_odbc
>    Affects Versions: 11.2.2, 11.3.0
>         Environment: Debian wheezy
> Realtime with MySQL and odbc
>            Reporter: A. Iglesias
>         Attachments: backtrace.txt
>
>
> Sporadically, we get a segfault in asterisk, that seems related to libmysqlclient liblibmyodbc:
> Apr 22 12:43:34 servidor kernel: [64998.226065] asterisk[1011]: segfault at 4e7671 ip 00007f1088d657c0 sp 00007f1062730fb8 error 7 in libmysqlclient.so.18.0
> May 14 08:04:41 servidor kernel: [1949064.842298] asterisk[31908]: segfault at 1bb8 ip 00007fb969704443 sp 00007fb94717bf50 error 4 in libmyodbc.so[7fb9696eb9696e2000+3c000]
> Always happens with incomings call: we receive a call, phones start ringing but asterisk is crashed.
> This is the dialplan for incoming calls:
> {noformat}
> exten => s,1,Set(LOCUCION=invierno)
>   same => n,Goto(EnterCall)
>   same => n(Festivo),Set(LOCUCION=invierno)
>   same => n,Goto(EnterCall)
>   same => n(Verano),Set(LOCUCION=verano)
>   same => n,Goto(EnterCall)
>   same => n(EnterCall),Background(locuciones/bienvenida)
>   same => n,Dial(SIP/internalname1&SIP/internalname2&SIP/internalname3&SIP/internalname4,10,two)
>   same => n,PlayBack(locuciones/${LOCUCION})
>   same => n,PlayBack(locuciones/buzon)
>   same => n,VoiceMail(0,s)
>   same => n,HangUp()
> {noformat}
> Find attached the backtrace file. Let me know if you need more info.
> Regards
> Alberto

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list